This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Add vendor information
Type: enhancement Stage:
Components: Versions: Python 3.11
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: FFY00, Marcus.Smith, christian.heimes, doko, dstufft, jaraco, ncoghlan, paul.moore, pradyunsg, steve.dower, willingc
Priority: normal Keywords:

Created on 2021-08-23 13:27 by FFY00, last changed 2022-04-11 14:59 by admin.

Messages (3)
msg400135 - (view) Author: Filipe Laíns (FFY00) * (Python triager) Date: 2021-08-23 13:27
In the effort of making the UX better with vendored Python versions, I think it would make sense to track and expose vendor information.

Initially, the vendor information would be comprised of two fields, the vendor string (eg. `Debian`) and the vendor name (eg. `debian`).

If specified, it would change the interpreter/installation in the following ways:
  - The vendor string would be shown in places like the IDLE shell (eg. [1])
  - The vendor name would be added to the installation paths (/usr/lib/python3.9 would become /usr/lib/python3.9-debian)
    - This would include scripts, so the interpreter would be called python3-debian, the vendors can then rename or symlink it to python3 if they want to have that be the default Python on the system

Additionally, I think we should add two new functions to the platform module, platform.vendor() and platform.vendor_name().

Overall, I think this would help out users identify the Python installation and avoid clashes between Python installations, even allowing parallel installations.
If I remember everything correctly, this should fix Matthias issues with bpo-43976. Matthias, could you confirm?

Any thoughts?

[1] new IDLE shell output

Debian Python 3.9.6 (default, Jun 30 2021, 10:22:16)
[GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
msg400138 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2021-08-23 13:59
A bunch of people, consisting of Filipe Lains himself, Geoffrey Thomas, Donald Stufft, Tzu-Ping Chung, Pradyun Gedam, Stefano Rivera, Elana Hashman, and myself (Matthias Klose), and with feedback from Carol Willing and Christian Heimes were preparing a PEP to address issues with vendored or system Python versions.  It looks like Filipe was unable to give feedback or follow-up after the initial meetings at PyCon.

I am unsure if having two different interpreters is a good solution, and it certainly requires some cooperation with distros.
msg400141 - (view) Author: Filipe Laíns (FFY00) * (Python triager) Date: 2021-08-23 15:10
> I am unsure if having two different interpreters is a good solution, and it certainly requires some cooperation with distros.

That is not the goal with this!

I think both this issue and the PEP are parallel. My goal here is to streamline the vendor patching of CPython, not propose parallel interpreters as an alternative.

Having discussed with you about your motivations and approach on packaging Python in Debian, I would definitely not expect you to adopt multiple interpreters in Debian.
The way this proposal mostly functionally impacts Debian is by isolating its namespace from the normal one, allowing you to drop changes like the dist-packages renaming -- because pip install will write to /usr/local/lib/python3.9-debian/site-packages and /usr/local Python installs will be looking at /usr/local/lib/python3.9/site-packages) -- and if I am not missing anything, unblocking bpo-43976.
Date User Action Args
2022-04-11 14:59:49adminsetgithub: 89145
2021-08-23 15:10:22FFY00setmessages: + msg400141
2021-08-23 13:59:21dokosetnosy: + paul.moore, ncoghlan, dstufft, pradyunsg, Marcus.Smith
messages: + msg400138
2021-08-23 13:27:53FFY00create