On 02. 06. 21 16:45, Matthias Klose wrote:
On 6/1/21 3:37 PM, Petr Viktorin wrote:
Hi!

FWIW, we plan for Fedora's system tools to have `-s` in Python shebangs by
default, meaning that the user’s Python packages (whether installed by `pip
install --user` or just placed in the current directory) don’t interfere with
the RPM installed software.
Extensible software like Ansible or Sphinx should leave off the `-s`, and
plugins for them should be installed using `pip install --user`.
Does that seem like a reasonable general suggestion?

Is this good enough?  We shortly discussed to have sys.path having *only* the
distro "site-packages" on sys.path, which would be 'python -s' additionally
without any locally pip installed library/module.  So maybe it's worth to
implement a python -D which is exactly doing this?

Yes, I think that, along with an option to skip adding the current directory, would be good additions.

One more note for the Alternatives section, to go along with the INSTALLER
discussion:
PEP 627 mentions one more way to mark an installed package as not modifiable by
Python-specific package manager: removing the RECORD file
(https://www.python.org/dev/peps/pep-0627/#optional-record-file).
It seems that this PEP obsolete one use case for missing RECORD. The other use
case remains -- it needs to be kept it in sync with distro actually installs,
which can be fragile.

sorry, I fail to understand/parse this section.

It is possible to mark individual installed packages so that Python tools (pip) won't uninstall them. This is done by removing (or not including) the RECORD file from the metadata. So, distros can already prevent pip from uninstalling (but not shadowing) their packages. I think this fact is as relevant to the draft PEP as the other discussion in "Alternatives".


A few nitpicks on terminology:

For practical reasons, I suggest using "distro" rather than "distribution" to
avoid a conflict with the meaning from https://packaging.python.org/glossary/
While this document disambiguates quite clearly, standardizing on "distro" could
make future discussions clearer.

PyPI meets the definition of such a distro; it might be good to exclude it
explicitly.

I'm fine with that change, as long as people understand that e.g. Conda and
HomeBrew are considered a distro as well.

Yes, I'd mention that explicitly. The current definition already does that.
_______________________________________________
Linux-sig mailing list -- linux-sig@python.org
To unsubscribe send an email to linux-sig-le...@python.org
https://mail.python.org/mailman3/lists/linux-sig.python.org/
Member address: arch...@mail-archive.com

Reply via email to