Re: pip install --user broken in debian testing?

[Barry Scott <barry@barrys-emacs.org>]

On 27 Feb 2023, at 22:40, ⁨Danial Behzadi دانیال بهزادی⁩ <⁨dani.behzi@ubuntu.com⁩> wrote:

As a developer who runs many Python apps with Systemd for years, I can say that using virtual environments was the only standard way even before this behavior change. It add no complexity and prevents a lot of things yo go wrong.

For my day job we package the python code in RPMs and control versions that way for Centos servers.

venv are one way, buyt not the only way.

Barry

This is the new standard for Python which Debian respects it too.

در ۲۷ فوریهٔ ۲۰۲۳ ۱۴:۱۹:۱۸ (UTC)، Thomas Ward <teward@thomas-ward.net> نوشت:

If I may make an observation, how would one implement these venvs properly then if something requires to be launchdd via systemd (custom services)? Or specialized daemons which do not properly behave as expected in venvs?

This is going to increase complexity massovely for end users who expect userspace module installation to work.  Was this decision a Debian level decision or an upstream Python decision?

Sent from my Galaxy

-------- Original message --------

From: Victor Westerhuis <victor@westerhu.is> 

Date: 2/26/23 17:56 (GMT-05:00) 

To: debian-mentors@lists.debian.org, Barry Scott <barry@barrys-emacs.org>, Danial Behzadi دانیال بهزادی <dani.behzi@ubuntu.com>

Subject: Re: pip install --user broken in debian testing? 

Barry Scott <barry@barrys-emacs.org> schreef op 26 februari 2023 21:36:20 CET:
>
>
>> On 26 Feb 2023, at 14:06, ⁨Danial Behzadi دانیال بهزادی⁩ <⁨dani.behzi@ubuntu.com⁩> wrote:
>> 
>> That's the new intended behavior. I you want non-debian python packages, install them in a non-debian python via virtual environments.
>
>The idea is to prevent installing into /usr not preventing install in $USER I hope.
According to the PEP it's both, and it actually makes sense. Python does not distinguish between packages in system-wide and user-specific locations.

Allowing non-virtualized installation of Python packages into the user-specific location could therefore break Python programs and libraries installed by apt/dpkg.

Virtualized installations do not cause issues and are still allowed using, for example, pipx or raw venvs.
>
>I think this is a major bug.
>
>Barry
>
>
>
>> 
>> 
>
>> 
>> در ۲۶ فوریهٔ ۲۰۲۳ ۱۰:۰۴:۲۰ (UTC)، Barry Scott <barry@barrys-emacs.org> نوشت:
>>> I have been using the following to add useful python based commands to my user locally:
>>> 
>>> $ python3 -m pip install --user <package>
>>> 
>>> For install I get this:
>>> 
>>> $ python3 -m pip install --user colour-text
>>> error: externally-managed-environment
>>> 
>>> × This environment is externally managed
>>> ╰─> To install Python packages system-wide, try apt install
>>>     python3-xyz, where xyz is the package you are trying to
>>>     install.
>>> 
>>>     If you wish to install a non-Debian-packaged Python package,
>>>     create a virtual environment using python3 -m venv path/to/venv.
>>>     Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
>>>     sure you have python3-full installed.
>>> 
>>>     If you wish to install a non-Debian packaged Python application,
>>>     it may be easiest to use pipx install xyz, which will manage a
>>>     virtual environment for you. Make sure you have pipx installed.
>>> 
>>>     See /usr/share/doc/python3.11/README.venv for more information.
>>> 
>>> note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
>>> hint: See PEP 668 for the detailed specification.
>>> 
>>> This look wrong to me as I am not installing into the systems site-packages.
>>> 
>>> Barry
>>> 
>