> On 27 Feb 2023, at 22:40, Danial Behzadi دانیال بهزادی > <[email protected]> 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 <[email protected] > <mailto:[email protected]>> نوشت: >> 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 <[email protected]> >> Date: 2/26/23 17:56 (GMT-05:00) >> To: [email protected], Barry Scott <[email protected]>, >> Danial Behzadi دانیال بهزادی <[email protected]> >> Subject: Re: pip install --user broken in debian testing? >> >> Barry Scott <[email protected]> schreef op 26 februari 2023 21:36:20 >> CET: >> > >> > >> >> On 26 Feb 2023, at 14:06, Danial Behzadi دانیال بهزادی >> >> <[email protected]> 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 <[email protected]> >> >> نوشت: >> >>> 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 >> >>> >> >
