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.