After upgrading pip from 1.4.x to 1.5 pip freeze outputs a list of my globally installed (system) packages instead of the ones installed inside of my virtualenv. I've tried downgrading to 1.4 again but that does not solve my problem. It's somewhat similar to this question only it's been working as expected for months. Is there any way to debug and/or repair this?
It seems like the virtualenv has no effect at all. Installing packages within it installs them globally too.
I had problems with pip installing packages globally instead of in the activated virtualenv too. Have a look at pip installing in global site-packages instead of virtualenv for the question (and the answer).
Basically, the solution consisted of modifying the shebang of the pip scripts within the virtualenv as they pointed to the wrong python installation.
Even if you have installed properly, but with global site packages visible to your virtualenv, still pip will list everything, unless you use pip list --local discussed here.
Related
I'm working on a DevOps project for a client who's using Python. Though I never used it professionally, I know a few things, such as using virtualenv and pip - though not in great detail.
When I looked at the staging box, which I am trying to prepare for running a functional test suite, I saw chaos. Tons of packages installed globally, and those installed inside a virtualenv not matching the requirements.txt of the project. OK, thought I, there's a lot of cleaning up. Starting with global packages.
However, I ran into a problem at once:
➜ ~ pip uninstall PyYAML
Not uninstalling PyYAML at /usr/lib/python2.7/dist-packages, owned by OS
OK, someone must've done a 'sudo pip install PyYAML'. I think I know how to fix it:
➜ ~ sudo pip uninstall PyYAML
Not uninstalling PyYAML at /usr/lib/python2.7/dist-packages, owned by OS
Uh, apparently I don't.
A search revealed some similar conflicts caused by users installing packages bypassing pip, but I'm not convinced - why would pip even know about them, if that was the case? Unless the "other" way is placing them in the same location pip would use - but if that's the case, why would it fail to uninstall under sudo?
Pip denies to uninstall these packages because Debian developers patched it to behave so. This allows you to use both pip and apt simultaneously. The "original" pip program doesn't have such functionality
Update: my answer is relevant only to old versions of Pip. For the latest versions, Pip is configured to modify only the files which reside only in its "home directory" - that is /usr/local/lib/python3.* for Debian. For the latest tools, you will get these errors when you try to delete the package, installed by apt:
For pip 9.0.1-2.3~ubuntu1 (installed from Ubuntu repository):
Not uninstalling pyyaml at /usr/lib/python3/dist-packages, outside environment /usr
For pip 10.0.1 (original, installed from pypi.org):
Cannot uninstall 'PyYAML'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.
The point is not that pip cannot install the package because you don't have enough permissions, but because it is not a package installed through pip, so it doesn't want to uninstall it.
dist-packages is where packages installed by the OS package manager reside; as they are handled by another package manager (e.g. apt on Ubuntu/Debian, pacman on Arch, rpm/yum on CentOS, ... ) pip won't touch them (but still has to know about them as they are installed packages, so they can be used to satisfy dependencies of pip-installed packages).
You should also probably avoid to touch them unless you use the correct package manager, and even so, they may have been installed automatically to satisfy the dependencies of some program, so you may not remove them without breaking it. This can usually be checked quite easily, although the exact way depends from the precise Linux distribution you are using.
I am managing several modules on an HPC, and want to install some requirements for a tool using pip.
I won't use virtualenv because they don't work well with our module system. I want to install module-local versions of packages and will set PYTHONPATH correctly when the module is loaded, and this has worked just fine when the packages I am installing are not also installed in the default python environment.
What I do not want to do is uninstall the default python's versions of packages while I am installing module-local versions.
For example, one package requires numpy==1.6, and the default version installed with the python I am using is 1.8.0. When I
pip install --install-option="--prefix=$RE_PYTHON" numpy==1.6
where RE_PYTHON points to the top of the module-local site-packages directory, numpy==1.6 installs fine, then pip goes ahead and starts uninstalling 1.8.0 from the tree of the python I am using (why it wants to uninstall a newer version is beyond me but I want to avoid this even when I am doing a local install of e.g. numpy==1.10.1).
How can I prevent pip from doing that? It is really annoying and I have not been able to find a solution that doesn't involve virtualenv.
You have to explicitly tell pip to ignore the current installed package by specifying the -I option (or --ignore-installed). So you should use:
PYTHONUSERBASE=$RE_PYTHON pip install -I --user numpy==1.6
This is mentioned in this answer by Ian Bicking.
pip is installing to global location rather than in the venv. I tried a lot of things but none worked. I found out that pip3 is missing from bin in my vienv. I have tried all of the below:
pip installing in global site-packages instead of virtualenv and
http://w3facility.org/question/pip-installing-in-global-site-packages-instead-of-virtualenv/
And many more...if you need i can paste more links. Please help.
Using a virtual environment with Python 3.4 provides helpful information about dealing with Python 3.x and virtualenv/pyevn.
Find instruction about how to install pip manually on pip.pypa.io.
The Red Hat yum package of Python 3.4 is broken, with pip missing. Other Python 3.4+ distributions might have the same problem.
When you create a virtual environment with:
pyvenv-3.4 py3
source py3/bin/activate
the environment should include pip automatically (in the environment/bin directory, not globally). If it does not, try downloading the pip and setuptools wheels manually as described in https://stackoverflow.com/a/33767179/948866. It's a little more work up front than installing pip the old way, but it makes pyvenv work properly.
I'm aware that there are similar questions on SO. This one, for example: What's the proper way to install pip, virtualenv, and distribute for Python?
I'd like to install these modules as per my Learn Python the Hard Way tutorial: http://learnpythonthehardway.org/book/ex46.html
I managed (I think) to install pip by using sudo easy_install pip but when I then ran pydoc modules I could not see it. So I'm not even sure it's installed.
The answer above in question 4324558 is difficult for me to understand: what's a bootstrap, what's curl and why would I set up a virtual environment? Yes, as a learner I should try to pick up as much as I can but I don't want to first create the universe, I just want to get the task at hand done.
How do I install these modules? Is it as complicated as it sounds in the quoted answer? The top voted answer says "Install virtualenv into a bootstrap virtual environment. Use the that virtual environment to create more. Since virtualenv ships with pip and distribute, you get everything from one install."
I really don't get what all that means. Isn't there something about the "Zen" of python and a one true way to get things done? Or am I out of context here? What is "the right way" to install these modules?
I tried:
pip install virtualenv in the terminal and received the following output:
Wheel installs require setuptools >= 0.8 for dist-info support.
pip's wheel support requires setuptools >= 0.8 for dist-info support.
Storing debug log for failure in /Users/myname/.pip/pip.log
I'm using a Mac and python 2.7
To solve your issue,
Just install (or upgrade) the setuptools:
sudo easy_install -U setuptools
Then you can run again: pip install virtualenv
Try adding 'sudo' in your command as-
sudo pip install virtualenv
It worked for me.
Have a look at Python Development Environment on Mac OS X Mavericks 10.9.
I followed these steps as well when trying to get Python 2.7 and Python 3.3 installed on OS X. It doesn't tell you how to install nose and distribute, but you should have a working environment and you can pick up from there.
I did have a problem using virtualenv and pip with Python 3, the question and solutions is available here.
I'm using pip on webfaction and it keeps trying to uninstall system packages and then failing. For example if I try to install Fabric, one of the requirements is pycrypto. When it tries to uninstall it, it fails.
Is there anyway to tell pip to not do this?
This is a common use scenario for virtualenv (aside from... all the time).
Build your app around a clean virtualenv so that you don't have to think about system packages ever again (mostly) in permission limited environments.
My guess is you have created the virtualenv with the --system-site-packages option, so it could use some packages installed system-wide.
If that's indeed what you did, try to create a clean virtualenv, and install all your dependencies inside it. This way, you'll never have to think of what packages are installed sytem-wide and what packages are installed in the virtualenv.
To do so, you can use --no-site-packages, which has now become a default virtualenv option.