Pip installs to unexpected place

Sat Apr 19 15:56:16 EDT 2025

On 4/19/2025 4:56 AM, Peter J. Holzer via Python-list wrote:
> On 2025年04月18日 13:08:36 -0400, Thomas Passin via Python-list wrote:
>> On 4/18/2025 11:38 AM, Peter J. Holzer via Python-list wrote:
>>> On 2025年04月18日 13:24:28 +1200, Greg Ewing via Python-list wrote:
>>>> 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".
>>>>>> It's not the application that looks into .local, it's Python. If you say
>>> that a system-installed Python shouldn't look into ~/.local, then you've
>>> just disabled that mechanism completely. If not then Python would
>>> somehow have to distinguish between system-installed and user-installed
>>> scripts. This isn't as easy as checking whether the path starts with
>>> /usr/bin or whether it belongs to root. Tying into the system's package
>>> manager doesn't look appealing to me (not to mention that it might be
>>> unacceptably slow).
>>>> Let's try a specific example. Let's say that PyQt6 v6.8.3 is installed in
>> the system site directory. The OS uses PyQt6 for some system purposes. Now
>> the user comes along and forces an install of PyQt6 v6.9.0 in the user site
>> directory. 6.9.0 has a bug that would crash one of the system's application
>> but not the user's programs. (This is not a far-fetched scenario).
>> Agreed. Also since PyQt6 is a GUI framework, I'm going to assume that
> those applications are supposed to be invoked by the user on their
> desktop, not by a cronjob controlled by the system.
>>>> When the system launches its application the PYTHONPATH will start with
>> system site directories; local user site directories will be on the
>> PYTHONPATH but since they come later, the python will use PyQt6 v6.8.3
>> because that will come first on the path. No crash here.
>>>> If the user has a program that actually does require the use of v6.9.0, he's
>> going to have to make sure that the user's local site directories come first
>> on the path. One way to do that is to set the PYTHONPATH to point to the
>> user's location.
>> This is IMHO not practical. The user would have to set PYTHONPATH for
> some programs, but not for others. You can't do this with .bashrc (or
> similar), the user would have to write a wrapper script for each of
> their programs which depend on something in ~/.local. Possible of course
> but cumbersome.
>> I like Oscar's suggestion that Python scripts provided by the
> distribution include -s in the shebang much better.
>> Or - what I tend to do - simply use a virtual environment for each
> script that needs a package that the system doesn't provide. But of
> course that's basically "disable/don't use .local" and all those venvs
> take space and need to be maintained.

My problem with venvs, especially if I have more than one, is that I 
eventually forget what they were for and what is different about each 
one. If there's only one and it's used for all non-system work, that's 
OK but beyond that and they tend to suffer knowledge rot.
>>> In what scenario is a system application going to load a wrong version of a
>> dependency from a user's site location?
>> When the user sets PYTHONPATH and then accidentally invokes the
> system-supplied application without resetting it first.
>>> The only one I can think of is for the user, with the help of sudo, or
>> by editing some system-enabled script, were to change the global
>> PYTHONPATH. That seems a stretch.
>> No, there doesn't have to be a global (in the sense that it applies to
> all users) PYTHONPATH for that to happen. You just need a PYTHONPATH
> that is set for all processes of that user - which the user can
> certainly set without sudo (usually by editing .bashrc or maybe using
> their desktop environment's settings dialog).

Yes, I agree and I wasn't thinking locally enough.