Re: Pip installs to unexpected place
Op 15/04/2025 om 20:31 schreef Mats Wichmann via Python-list: To be clear: you do not have to activate a virtualenv to use *Python* from it. If you just call the python by the path it's in, it figures everything out (and sets some variables you can query vi sysconfig if you have reason to actually need those details (look for installation schemes). What activating gives you is some path fiddling, and some prompt fiddling (although the prompt fiddling keeps saying it's deprecated). The latter is a visual clue; the former means you can also find *other* commands installed in the virtualenv - including pip. /path/to/virtualenv//bin/python -m pip install ... will work whether you activated or not. pip install ... finds the first command in your PATH named pip, which may or may not be the one in the virtualenv, *unless* you've activated it, because that's the only way the virtualenv bin directory ends up early in your path. And the pip command that is found and run will use it's own settings regarding where to install packages, even if you activated a virtualenv. For example, you can't use /usr/bin/pip to install something in a virtualenv. To install something in a virtualenv, you need to use the pip in that virtualenv (either by first activating that venv, or by running something like venv/bin/pip, or venv). (Of course to do that pip needs to be installed in that venv. That might or might not be the case depending on how the venv was created.) I kinda get the feeling that something like that is going on here. -- "There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened." -- Douglas Adams, The Restaurant at the End of the Universe -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 4/17/2025 4:58 AM, Roel Schroeven via Python-list wrote: Op 15/04/2025 om 20:31 schreef Mats Wichmann via Python-list: To be clear: you do not have to activate a virtualenv to use *Python* from it. If you just call the python by the path it's in, it figures everything out (and sets some variables you can query vi sysconfig if you have reason to actually need those details (look for installation schemes). What activating gives you is some path fiddling, and some prompt fiddling (although the prompt fiddling keeps saying it's deprecated). The latter is a visual clue; the former means you can also find *other* commands installed in the virtualenv - including pip. /path/to/virtualenv//bin/python -m pip install ... will work whether you activated or not. pip install ... finds the first command in your PATH named pip, which may or may not be the one in the virtualenv, *unless* you've activated it, because that's the only way the virtualenv bin directory ends up early in your path. Or you can cd to the venv directory and it will be first on the pythonpath. And the pip command that is found and run will use it's own settings regarding where to install packages, even if you activated a virtualenv. For example, you can't use /usr/bin/pip to install something in a virtualenv. pip detects if you are running in a venv and changes its behavior to match. To install something in a virtualenv, you need to use the pip in that virtualenv (either by first activating that venv, or by running something like venv/bin/pip, or venv). (Of course to do that pip needs to be installed in that venv. That might or might not be the case depending on how the venv was created.) I kinda get the feeling that something like that is going on here. IMHO pip should always be run as a module, e.g., python3 -m pip. This way you always get the same pip and environment as the python executable that is being used. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
> Also... when installing stuff with pip --user, it is always a package > that is not installed for the system (usually not even available for > the system). How can that "break system packages"? pip installs dependencies. Dependencies may disagree on the version with the system packages. This is a difference between eg. how conda works and pip. Conda is an actual package manager: it ensures that all packages in a particular environment agree on version requirements. pip will break your environment in subsequent installs because it doesn't keep track of what was installed before. On top of this, pip may, in general, cause any amount of damage to your system regardless of where or how you install it because by default it's allowed to build wheels from source packages. The build may run whatever code, including formatting hard drives, mining bitcoin etc. The reason it doesn't happen very often is that package maintainers kind of trust each other to be nice. There aren't really any safeguards to prevent malicious actors from doing this, but you would have to want to install their package for some reason. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 4/17/25 15:15, Grant Edwards via Python-list wrote: On 2025-04-17, Left Right via Python-list wrote: Also... when installing stuff with pip --user, it is always a package that is not installed for the system (usually not even available for the system). How can that "break system packages"? pip installs dependencies. Dependencies may disagree on the version with the system packages. Good point. I don't generally allow pip to install dependencies, so I forgot about that source of conflict. But as far as I can see, it still can only break stuff for the user, not for the system. The system is never going to look in my ~/.local/lib/python* directories. Sure, and it's "your fault" (sic) if you break yourself. You and I can maybe accept that. But it's usually not obvious that you're done anything to break stuff - you just asked to install something, according to the instructions you read on the project's website, which it's reasonable (?) to expect reflects best practices. Usually a simple "pip install". Say you've been using "MLwiz" installed via a system package. It has two dozen dependencies, some of which have further deps. And it works great. Then you install "Chatbridge" via pip, and it brings with it its own dependencies. It's not really useful to refuse to let it bring its own deps with it since there may be version-specific requirements on its deps, which that project has reasons for. So now you've got a few pkgs in the system with different versions in your .local, and you can't run MLwiz any longer, because a .local pkg (picked up first) conflicts with the requirements of MLwiz. There's just not a really great answer to this. "Use a virtualenv". Fine, but that's still daunting to many, and not necessarily as well described as it could be, and the choice of the word "virtual" in the name makes it sound more complex than it actually is. Projects can certainly do better at describing installation scenarios - at least if they have more than a trivial number of deps, where the conflict chances go up rapidly. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 18/04/25 9:41 am, Mats Wichmann wrote: There's just not a really great answer to this. Seems to me a system-installed application shouldn't be looking in the user's .local packages in the first place. That should only be for things the user has installed "for this user". -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 2025-04-17, Left Right via Python-list wrote: >> Also... when installing stuff with pip --user, it is always a package >> that is not installed for the system (usually not even available for >> the system). How can that "break system packages"? > > pip installs dependencies. Dependencies may disagree on the version > with the system packages. Good point. I don't generally allow pip to install dependencies, so I forgot about that source of conflict. But as far as I can see, it still can only break stuff for the user, not for the system. The system is never going to look in my ~/.local/lib/python* directories. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
