• #!/usr/bin/python3 vs virtualenv

    From Marc Glisse@21:1/5 to All on Fri Mar 3 16:30:01 2023
    Hello,

    I recently reported
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032283 , and Dmitry suggested discussing it on this mailing list.

    Virtual environments work by adding some version of Python (possibly just
    a symlink to the system one) at the beginning of PATH. Debian policy for
    Python scripts is to use #!/usr/bin/python3 and **not** #!/usr/bin/env
    python3, so they are not affected.

    I think there are 2 types of Python scripts. The first type is
    applications for end users, like hg or calibre (it is possible that the existence of plugins makes my choice of examples a bad one). If I have
    some strange Python virtual environment active, I am happy that the Debian policy prevents the virtual environment from breaking those applications (although I may still be able to break them with PYTHONPATH).

    The second type is targeted at developers, like sphinx-build. If I
    activate a virtual environment that contains tensorflow, it is because I
    need `import tensorflow` to work inside sphinx-build, but now the Debian
    policy prevents it.

    As discussed in the bug report, there are workarounds. The question here
    is whether it would make sense to amend the policy for some types of
    scripts. The answer is probably no, but it seems worth checking what
    people think.

    The suggestion to install a copy of sphinx in the virtual environment is a
    step towards the advice I hear around me but don't really want to follow: "Developers should use conda, system python packages are only for system applications" :-(

    (thanks a lot to everyone here working on packaging Python stuff in
    Debian)

    --
    Marc Glisse

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?RGFuaWFsIEJlaHphZGkg2K/Yp@21:1/5 to All on Fri Mar 3 19:50:01 2023
    ------WRPLGJ3IJBBTMOOIDSQTFEF2I6297W
    Content-Type: text/plain;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    You just want to install sphinx via pip in the virtual environment too. Each venv should be atomic and isolated which means not depended to system packages.
    ------WRPLGJ3IJBBTMOOIDSQTFEF2I6297W
    Content-Type: text/html;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <!DOCTYPE html><html><body><div dir="auto">You just want to install sphinx via pip in the virtual environment too. Each venv should be atomic and isolated which means not depended to system packages.</div></body></html>
    ------WRPLGJ3IJBBTMOOIDSQTFEF2I6297W--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeremy Stanley@21:1/5 to All on Fri Mar 3 20:20:01 2023
    On 2023-03-03 18:44:19 +0000 (+0000), Danial Behzadi دانیال بهزادی wrote:
    You just want to install sphinx via pip in the virtual environment
    too. Each venv should be atomic and isolated which means not
    depended to system packages.

    However a venv can be made to use system packages if you use the --system-site-packages option when creating it.
    --
    Jeremy Stanley

    -----BEGIN PGP SIGNATURE-----

    iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmQCR5pfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WClEphAAwCPPIRNM+Ac0khbGY5vmDKrMkG6vK9/ULrdh3TUyiBO/3oARsejwLg1l 6NIVCSOMhq1JjDR0bYx9sHOqkTEVsT3+s/ozJT0vckl1cYh8EyRGhGI+zkWaOb0Q I/2xuPq51JAqQjPYHXruSHvXPDElr0LHewqrpW2KcJnhsYTeQXY/BLVFlKCaIDuB ooudlhzGViG74mO9Jk4BIhoiU0aatTNe80s9zNbTvIff39XWRoRFBcbMGAfOhAen +ZtlBbtmInyPJCpQDz7mmUX/dw9Lqy3MKpofeR/lTf45H1Dkc1m50AJwpR1W4kqh xuNTxk1wWvxvDkQDsRvv5Dp9fERRE/Mug4uIXAj1nJIaiTFH9cBcbqZ95AX0C4ep zCapUjN67aZcRpG59fHzjJgGkQ/hnQX0dYerx5q/FOsfdXY71TXSvMhw1clpLAFz AosYqQpSiLyN1F/WpfTtYF6cBqS63X92334DtPddk19Fb4g1aVj9bO6KxYyEKzqV kl1fJuDIcZlRIJokfzchUYKAv1dZ5aY10/hib0aGFaC9Cymf7Vcs9oz8cEJg1azT S08Y4dDJ1PX9JyK+yPZcnXOt2P0JBSBya7prH7ORsTTs+Sbt9h2itmdSJOFvMG5F IqbE2f/KU9p7ToEgsnHHZwvqQWLOH5rEzBpfVBdsOjFn6PObhWA=
    =1+HG
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32
  • From Jorge Moraleda@21:1/5 to fungi@yuggoth.org on Fri Mar 3 21:30:01 2023
    Would it be hard to support both philosophies?

    I would like to suggest a couple of configuration options that by default disallow using pip outside a virtual environment but that users with root privilege can modify by editing a config file (probably somewhere in /etc)
    and that would enable using pip outside a virtual environment, both as root
    and as regular user respectively.

    I feel this would satisfy the needs of regular users to be protected
    against accidentally breaking their system while enabling power users to
    have full control of their computer and enjoy the simplicity of a single environment. Clearly this discussion suggests that debian has both types of users and we should support them both if we can.

    Thank you.

    On Fri, Mar 3, 2023 at 2:17 PM Jeremy Stanley <fungi@yuggoth.org> wrote:

    On 2023-03-03 18:44:19 +0000 (+0000), Danial Behzadi دانیال بهزادی wrote:
    You just want to install sphinx via pip in the virtual environment
    too. Each venv should be atomic and isolated which means not
    depended to system packages.

    However a venv can be made to use system packages if you use the --system-site-packages option when creating it.
    --
    Jeremy Stanley


    <div dir="ltr"><div class="gmail_default" style="font-size:small">Would it be hard to support both philosophies? <br><br>I would like to suggest a couple of configuration options that by default disallow using pip outside a virtual environment but that
    users with root privilege can modify by editing a config file (probably somewhere in /etc) and that would enable using pip outside a virtual environment, both as root and as regular user respectively.<br><br></div><div class="gmail_default" style="font-
    size:small">I feel this would satisfy the needs of regular users to be protected against accidentally breaking their system while enabling power users to have full control of their computer and enjoy the simplicity of a single environment. Clearly this
    discussion suggests that debian has both types of users and we should support them both if we can.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thank you.<br></div></div><br><div
    class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 3, 2023 at 2:17 PM Jeremy Stanley &lt;<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-
    left:1px solid rgb(204,204,204);padding-left:1ex">On 2023-03-03 18:44:19 +0000 (+0000), Danial Behzadi دانیال بهزادی wrote:<br>
    &gt; You just want to install sphinx via pip in the virtual environment<br> &gt; too. Each venv should be atomic and isolated which means not<br>
    &gt; depended to system packages.<br>

    However a venv can be made to use system packages if you use the<br> --system-site-packages option when creating it.<br>
    -- <br>
    Jeremy Stanley<br>
    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeremy Stanley@21:1/5 to Jorge Moraleda on Fri Mar 3 21:50:02 2023
    On 2023-03-03 15:29:09 -0500 (-0500), Jorge Moraleda wrote:
    Would it be hard to support both philosophies?

    I would like to suggest a couple of configuration options that by default disallow using pip outside a virtual environment but that users with root privilege can modify by editing a config file (probably somewhere in /etc) and that would enable using pip outside a virtual environment, both as root and as regular user respectively.

    I feel this would satisfy the needs of regular users to be protected
    against accidentally breaking their system while enabling power users to
    have full control of their computer and enjoy the simplicity of a single environment. Clearly this discussion suggests that debian has both types of users and we should support them both if we can.
    [...]

    "Power users" who like to break their systems can simply `sudo pip
    install --break-system-packages foo` or even just `sudo rm /usr/lib/python3.11/EXTERNALLY-MANAGED` and then do whatever they
    want anyway. It doesn't seem to me like there's much need for a
    config option that does that for you, and adding one would imply
    that Debian will help you fix things once you've done it. This
    feature is simply a guard rail for users who otherwise wouldn't know
    where the edge of that cliff is located.

    There are already solutions for your power users, but as is often
    said in such situations: If it breaks you get to keep the pieces.
    Have fun!
    --
    Jeremy Stanley

    -----BEGIN PGP SIGNATURE-----

    iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmQCW9ZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCmxzA/9EusnW2GK8l+4JW/y72YL5Z89UyxG9MneN/lKoqJTNPizHWXFgScrBW11 B9mhT9tVkHpN9fBlcf2ThG3m3IOCLtrQlSV0gAoVUCuaPVBDc9cU/WBySCEGMAYe 6/ibI3Mpl7oVCv1E+qxB19IPTlrkSjR9Zxk7At7Sa2zk16q9rtWRwqDCEMbmy+sg WGgniViy2CiB+GppwJ+fz9vCjwswvFxfrlo9mip6eo5yvvjdAAeZsm+nnz8lQboU PWE+rtttuZT1qJ5kZpiXEC60Q5Jg0WI7APLipr1V/19fUFIxleeTTpzG+jsba6z6 U1L604MrmPSN/H+O27IxXDpxkvo4UTSzUYSitr2IYVOXcdBIJEbegCKhqpC9OmVP mpWjrwM++Jge5eIRZUBFAFX+Yo2BSmly2YQONTAI7gGDnDiVggvhtG9pHZN5vHeu Oxc5IOW3PtrGrOOtUqkPSDj9IMJ1pqd40VbYENlpEZiTwCF5s8CRW5kxCcZOoXE2 PgLgG/bk+G7etr9DzZAzG55MTT2xOao7wQEntIZ0MDVpHtXdH6zB1xa+G1MdvoMr DgagO1oHJWffTA7SvQagdlFaHFPL85Dmz8BIk8+QACvRDui3MNasbWieoFIrwXe6 TUfQN9u+LepznAEH/IiNfJ0+0GjN5A7UF4yUT8nDOv4abRbRAhw=
    =QHpx
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32
  • From Dmitry Shachnev@21:1/5 to Marc Glisse on Fri Mar 3 21:50:02 2023
    Hi all,

    On Fri, Mar 03, 2023 at 04:10:50PM +0100, Marc Glisse wrote:
    Hello,

    I recently reported
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032283 , and Dmitry suggested discussing it on this mailing list.

    Virtual environments work by adding some version of Python (possibly just a symlink to the system one) at the beginning of PATH. Debian policy for
    Python scripts is to use #!/usr/bin/python3 and **not** #!/usr/bin/env python3, so they are not affected.

    I think there are 2 types of Python scripts. The first type is applications for end users, like hg or calibre (it is possible that the existence of plugins makes my choice of examples a bad one). If I have some strange
    Python virtual environment active, I am happy that the Debian policy
    prevents the virtual environment from breaking those applications (although
    I may still be able to break them with PYTHONPATH).

    I want to add that this concern applies to Sphinx too.

    Newer versions of its dependencies (e.g. docutils or jinja2) can easily break Sphinx. As well as incompatible versions of some Sphinx extensions installed from PyPI.

    --
    Dmitry Shachnev

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEE5688gqe4PSusUZcLZkYmW1hrg8sFAmQCW8EACgkQZkYmW1hr g8sxVw/8DKIVssEfUTRDbFNy2nl5xMg73ZwI8MLQIrZz+2YmjqYFM0YTkCF13m/4 eRaBIMmVMJ3dRKuyBO64B9xTKntYEMc/n0La6LReVAUr9yi840x5MISsp/dou48+ XwbORwI1zOeopEPnYBXgtlljFS/yYvqD9VWM1+Gj2Q+81EmvfM/wwiRUQ0JqOwGt XyARRT7CMN93zpvZanpQIiaq1aoyLobWhvNgirocUPWiTinAYO9mLB3p0q3t4RFl ClR5dDJ34+SK7gjvkhg07oBe/UUvUY3RbjOydoVayhB/k6cvZbUeIZ1f8mZfUycZ K9NcCBbk2yQ40FAvJ+CuGUpywqgGoBok2bpxL/2Kiq1MX0tGSzbwLOqIWKC4PLFK JUgpSLYStdsIGJM8I2q1YuOwfWcZ3x5xc21QdwRp8OZLh5ebBnHDLXSi51gkASur 09B8HIEnuHy3gLcUCXBFTXxJ/agbX2qgguH/GT89D1lJ2DOR1pzZ+BMDD9hEvsGx jrBADWs+/odsTcM+DxVxVgbHAAmmAZPWofHwMdYeyfDXOe++SW0l4dFfupeeYRT1 IZzaw5JoRAyMmSA2fYR+0u5QJ8d67Hvzmey+hF3u2pq+mloIHgWX+AxhANJvwI7G JszNSCtAvPkUf+6zXUpZ5dfRyhlR/yjmxCyp/9UmrGaulE+JOpE=
    =YCMS
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeremy Stanley@21:1/5 to Jorge Moraleda on Fri Mar 3 22:50:01 2023
    On 2023-03-03 16:22:11 -0500 (-0500), Jorge Moraleda wrote:
    I did not know about `sudo pip install --break-system-packages
    foo` or `sudo rm /usr/lib/python3.11/EXTERNALLY-MANAGED` (Frankly
    I only knew about this issue what I have read on this discussion).
    [...]

    They come from a reading of the pip documentation and associated
    PEP-668 specification respectively. I do hope power users read
    documentation before they choose to break their systems.

    Be aware that the second approach I mentioned is removing a file
    which gets installed by the libpython3.11-stdlib package, so will
    end up getting replaced each time you upgrade that package as it's
    not a conffile. It's a reasonable approach for things like container
    base images where subsequent image build steps use pip to install
    packages into the container, but it would be annoying for a "normal"
    system where you upgrade packages without building entirely new
    images.

    The pip install command-line option is more of a user-facing escape
    hatch, since it's clearly worded to let you know that it can quite
    easily render existing Python applications inoperable if you choose
    to install things into user or system site directories with pip.
    --
    Jeremy Stanley

    -----BEGIN PGP SIGNATURE-----

    iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmQCaRxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCkMhxAApq+pBfoF+ISvHH3P3l9IMAnBBLA+xWqQbU0+c4E6NwfB0nYIRyhQiNxW Qq+sP9CxKs/aI8DwBIavXQxITo0F9gqzrl7BznovCNo8DDYpWu9N10EFbb0UPbSw kn4ni9Wigl62ncO39Bt3eRl7H2YCtFbRnQNBSrEpmQwV3c90WC87aafe8TW9KR9/ ir7ehIZHHTA47jga/bWySGKudInha1TGwiF4kY9pk9y/oYk57x6j2dKa2Ir1iEeV kSlbEOv2FQ1H8eZwfwqbzkaKMlKiYuz/TimeDoCme6C8dBpqF47HDRJiLEqTYI2E 0E0z+NltAeTYLFHBN29WaGjGKfMwE6qDLUhKMBZFO1XwXG/kPO1Gf8jm6fMRtKjq 095HML0d+IYhHP21MbJqAYsVD1A91M/tT1kXvs8GnBcoL9nZYceQiCzzRTShBeuf o338b96xLSzLJueaZDihnS1GEpu1sfGmvTz2r3JVDmW0SMJ1st5TqZ02AyLvbYCS BH7a3ohr+QTvEr+1lKU6QYTtklb1XuwfWBb17rMdm865dyeFLcFjCBASDDH50ibd yXbZcTgj0vGvRG70IPwt4a4bDtBKrPmlhVvARLaNQ/q6sSBe3l/CpLbTEjotZhIo IRptFLLbkQwCCJ0PFPhNDXJ6Qqy9dnadCvNTJF4GMaewoRP69VI=
    =QIxR
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32
  • From Jorge Moraleda@21:1/5 to fungi@yuggoth.org on Fri Mar 3 22:30:01 2023
    Jeremy, Thank you for your quick reply!

    I did not know about `sudo pip install --break-system-packages foo` or
    `sudo rm /usr/lib/python3.11/EXTERNALLY-MANAGED` (Frankly I only knew about this issue what I have read on this discussion). This is very helpful and
    it really changes my outlook on this topic.

    IMHO the existence of these options completely satisfies the requirements
    of advanced users. In particular because, if I understand it correctly, the second of these options would leave the configuration as it used to be in previous releases of debian for those who want that.

    So then, for those that raised the issue, were you aware of these
    approaches? Will either of them satisfy your requirements? And if not,
    could you elaborate further on why not?

    Thank you again.

    On Fri, Mar 3, 2023 at 3:43 PM Jeremy Stanley <fungi@yuggoth.org> wrote:

    On 2023-03-03 15:29:09 -0500 (-0500), Jorge Moraleda wrote:
    Would it be hard to support both philosophies?

    I would like to suggest a couple of configuration options that by default disallow using pip outside a virtual environment but that users with root privilege can modify by editing a config file (probably somewhere in
    /etc)
    and that would enable using pip outside a virtual environment, both as
    root
    and as regular user respectively.

    I feel this would satisfy the needs of regular users to be protected against accidentally breaking their system while enabling power users to have full control of their computer and enjoy the simplicity of a single environment. Clearly this discussion suggests that debian has both types
    of
    users and we should support them both if we can.
    [...]

    "Power users" who like to break their systems can simply `sudo pip
    install --break-system-packages foo` or even just `sudo rm /usr/lib/python3.11/EXTERNALLY-MANAGED` and then do whatever they
    want anyway. It doesn't seem to me like there's much need for a
    config option that does that for you, and adding one would imply
    that Debian will help you fix things once you've done it. This
    feature is simply a guard rail for users who otherwise wouldn't know
    where the edge of that cliff is located.

    There are already solutions for your power users, but as is often
    said in such situations: If it breaks you get to keep the pieces.
    Have fun!
    --
    Jeremy Stanley


    <div dir="ltr"><div class="gmail_default" style="font-size:small">Jeremy, Thank you for your quick reply!<br><br> I did not know about `sudo pip install --break-system-packages foo` or  `sudo rm /usr/lib/python3.11/EXTERNALLY-MANAGED` (Frankly I only
    knew about this issue what I have read on this discussion). This is very helpful and it really changes my outlook on this topic.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">IMHO the
    existence of these options completely satisfies the requirements of advanced users. In particular because, if I understand it correctly, the second of these options would leave the configuration as it used to be in previous releases of debian for those
    who want that.<br><br>So then, for those that raised the issue, were you aware of these approaches? Will either of them satisfy your requirements? And if not, could you elaborate further on why not?<br></div><div class="gmail_default" style="font-size:
    small"> <br></div><div class="gmail_default" style="font-size:small">Thank you again.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 3, 2023 at 3:43 PM Jeremy Stanley &lt;<a href="mailto:fungi@yuggoth.org">
    fungi@yuggoth.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2023-03-03 15:29:09 -0500 (-0500), Jorge Moraleda wrote:<br>
    &gt; Would it be hard to support both philosophies?<br>
    &gt; <br>
    &gt; I would like to suggest a couple of configuration options that by default<br>
    &gt; disallow using pip outside a virtual environment but that users with root<br>
    &gt; privilege can modify by editing a config file (probably somewhere in /etc)<br>
    &gt; and that would enable using pip outside a virtual environment, both as root<br>
    &gt; and as regular user respectively.<br>
    &gt; <br>
    &gt; I feel this would satisfy the needs of regular users to be protected<br> &gt; against accidentally breaking their system while enabling power users to<br>
    &gt; have full control of their computer and enjoy the simplicity of a single<br>
    &gt; environment. Clearly this discussion suggests that debian has both types of<br>
    &gt; users and we should support them both if we can.<br>
    [...]<br>

    &quot;Power users&quot; who like to break their systems can simply `sudo pip<br>
    install --break-system-packages foo` or even just `sudo rm<br> /usr/lib/python3.11/EXTERNALLY-MANAGED` and then do whatever they<br>
    want anyway. It doesn&#39;t seem to me like there&#39;s much need for a<br> config option that does that for you, and adding one would imply<br>
    that Debian will help you fix things once you&#39;ve done it. This<br>
    feature is simply a guard rail for users who otherwise wouldn&#39;t know<br> where the edge of that cliff is located.<br>

    There are already solutions for your power users, but as is often<br>
    said in such situations: If it breaks you get to keep the pieces.<br>
    Have fun!<br>
    -- <br>
    Jeremy Stanley<br>
    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Julian Gilbey@21:1/5 to Jorge Moraleda on Sun Mar 5 11:50:01 2023
    On Fri, Mar 03, 2023 at 04:22:11PM -0500, Jorge Moraleda wrote:
    Jeremy, Thank you for your quick reply!

    I did not know about `sudo pip install --break-system-packages foo` or  `sudo rm
    /usr/lib/python3.11/EXTERNALLY-MANAGED` (Frankly I only knew about this issue what I have read on this discussion). This is very helpful and it really changes
    my outlook on this topic.

    The --break-system-packages option is noted in /usr/share/doc/python3.11/README.venv, and this file is mentioned in
    the NEWS file for python3.11. The
    /usr/lib/python3.11/EXTERNALLY-MANAGED file is not mentioned there; I personally think that having to type --break-system-packages every
    time one installs a package via pip globally or on a per-user basis is
    safer, as it reminds you that you run risks doing so.

    Best wishes,

    Julian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jorge Moraleda@21:1/5 to julian@d-and-j.net on Sun Mar 5 13:00:01 2023
    FWIW, I am one of those power users that develop python applications and
    prefer the simplicity of a single environment. In my personal experience, installing using `sudo pip` (or user pip, which I don't do at all) is not a frequent operation for users that choose to manage a single environment. Personally, I use it only after searching in apt and confirming the package
    is not there. Having to type --break-system-packages every time when I have
    to do it is a good solution for me that I find completely reasonable.

    Thank you!

    On Sun, Mar 5, 2023 at 5:47 AM Julian Gilbey <julian@d-and-j.net> wrote:

    On Fri, Mar 03, 2023 at 04:22:11PM -0500, Jorge Moraleda wrote:
    Jeremy, Thank you for your quick reply!

    I did not know about `sudo pip install --break-system-packages foo` or
    `sudo rm
    /usr/lib/python3.11/EXTERNALLY-MANAGED` (Frankly I only knew about this
    issue
    what I have read on this discussion). This is very helpful and it really
    changes
    my outlook on this topic.

    The --break-system-packages option is noted in /usr/share/doc/python3.11/README.venv, and this file is mentioned in
    the NEWS file for python3.11. The
    /usr/lib/python3.11/EXTERNALLY-MANAGED file is not mentioned there; I personally think that having to type --break-system-packages every
    time one installs a package via pip globally or on a per-user basis is
    safer, as it reminds you that you run risks doing so.

    Best wishes,

    Julian


    <div dir="ltr"><div class="gmail_default" style="font-size:small">FWIW, I am one of those power users that develop python applications and prefer the simplicity of a single environment. In my personal experience, installing using `sudo pip` (or user pip,
    which I don&#39;t do at all) is not a frequent operation for users that choose to manage a single environment. Personally, I use it only after searching in apt and confirming the package is not there. Having to type --break-system-packages every time
    when I have to do it is a good solution for me that I find completely reasonable.<br><br></div><div class="gmail_default" style="font-size:small">Thank you!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 5, 2023
    at 5:47 AM Julian Gilbey &lt;<a href="mailto:julian@d-and-j.net">julian@d-and-j.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Mar 03, 2023 at
    04:22:11PM -0500, Jorge Moraleda wrote:<br>
    &gt; Jeremy, Thank you for your quick reply!<br>
    &gt; <br>
    &gt; I did not know about `sudo pip install --break-system-packages foo` or  `sudo rm<br>
    &gt; /usr/lib/python3.11/EXTERNALLY-MANAGED` (Frankly I only knew about this issue<br>
    &gt; what I have read on this discussion). This is very helpful and it really changes<br>
    &gt; my outlook on this topic.<br>

    The --break-system-packages option is noted in<br> /usr/share/doc/python3.11/README.venv, and this file is mentioned in<br>
    the NEWS file for python3.11.  The<br>
    /usr/lib/python3.11/EXTERNALLY-MANAGED file is not mentioned there; I<br> personally think that having to type --break-system-packages every<br>
    time one installs a package via pip globally or on a per-user basis is<br> safer, as it reminds you that you run risks doing so.<br>

    Best wishes,<br>

       Julian<br>
    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Glisse@21:1/5 to All on Sun Mar 5 14:20:01 2023
    (sorry for replying to a random message, I am not subscribed to the list)

    I don't use `sudo pip`, too risky. I used to use pip to install packages
    with the implicit --user option (for things not available via apt). And I
    am aware of --break-system-packages, I used it the first time pip
    complained about an externally managed environment so I could keep working
    as before.

    I decided to follow the recommandations and use a virtual environment.
    And, in order to benefit from the packaging done in Debian, I thought I
    could use --system-site-packages and restrict pip to a few things that
    Debian does not provide.

    I now see that this was too optimistic. For now I'll use `python -m sphinx.cmd.build` as a workaround, but the next time I hit some issue I'll probably end up using conda, like everyone else. It just feels sad to see
    all the effort done in packaging Python things in Debian end with the recommendation not to use them :-(

    Thank you all for the advice,

    --
    Marc Glisse

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefano Rivera@21:1/5 to All on Thu Mar 9 23:40:01 2023
    Hi Julian (2023.03.05_10:47:08_+0000)
    the NEWS file for python3.11. The
    /usr/lib/python3.11/EXTERNALLY-MANAGED file is not mentioned there

    It was mentioned, but I've expanded on that in 3.11.2-5, and even more
    in the next upload:

    https://salsa.debian.org/cpython-team/python3/-/blob/master/debian/README.venv

    SR

    --
    Stefano Rivera
    http://tumbleweed.org.za/
    +1 415 683 3272

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)