1

In my home, I have a directory named lib/python2.7 (there are actually five directories like that, for different python versions). Since this is a shared hosting (Webfaction), that directory is fundamental to me. There, I have stuff like virtualenv and virtualenvwrapper installed, since as customer of a shared hosting, I have no access to sudo and installing global packages.

However, when I create a virtualenv:

$ mkvirtualenv myenvironment
$ workon myenvironment
$ which pip
# outputs the myenvironment's path to pip
$ pip freeze

The command shows the whole packages list under my lib/python2.7 (this includes the same virtualenv packages, and conflicting packages I have due to... legacy... reasons). This also annoys me if I want to install a package which is the name of a package in lib/python2.7 since it does not allow me to update it.

Right inside the workon environment, I try to check whether the PYTHONPATH has weird stuff, but it is empty:

$ echo $PYTHONPATH
# shows a blank line

It is also empty if I try that command out of any virtual environment.

It seems that --no-site-packages is default but solves just part of the problem. This means: pip freeze | wc -l displays a lesser value when in an environment than when executing globally, out of any environment, which tells me that there are certain already-provided packages that are being excluded and are from the hosting itself (and not installed by me since, again, the hosting is shared and I don't have access to global space).

My question is: How can I solve this? I want my virtualenv not list the packages in $HOME/lib/python2.7

Please avoid dupe-linking to this question, nothing was useful there and still does not have an accepted answer. I wrote this question after reading and trying each solution in that question

Community
  • 1
  • 1
Luis Masuelli
  • 12,079
  • 10
  • 49
  • 87

2 Answers2

2

I think you need to specify python version. You can specify python version with which you want to create virtual environment using command like

virtualenv -p /usr/bin/python3.4 virt/virtname --no-site-packages

Because when you not specify a python version, virtualenv creates a environment with pythonv2.7 and hence all packages end up in the folder you mentioned.

Rajesh Yogeshwar
  • 2,111
  • 2
  • 18
  • 37
  • This worked for me, but the format of the -p flag was different: `virtualenv --python=python3.6 --no-site-packages venv`. The default is the interpreter that virtualenv was installed with. – Jack Nov 03 '19 at 15:43
1

Found the solution after deeply digging. This is a Webfaction custom but this could apply to any installation like this if the problem occurs.

The core of the problem is that Webfaction configured a sitecustomize.py file for us. The file is located at /usr/local/lib/pythonX.Y/sitecustomize.py and adds by itself the contents of ~/lib/pythonX.Y (and conditionally the contents of any python app under ~/webapps if you are working under a directory of it to run a python script).

Even when the virtualenv's python executable is a different one, it will load the said sitecustomize.py file each time it runs as the base python executable does.

The workaround here? Create an empty sitecustomize.py in your virtualenv to override the other:

touch ~/.virtualenvs/yourvenv/lib/pythonX.Y/sitecustomize.py

And it will work. Take this as reference if you are stuck here like I was

Notes: Replace X.Y on each case with the corresponding version you are working. Additionally remember: You cannot remove or edit the base sitecustomize.py since you are in a shared hosting, in this case. However, overriding will work for each case as long as you do this for every virtualenv you want.

Luis Masuelli
  • 12,079
  • 10
  • 49
  • 87