Issue 44982: Add vendor information (original) (raw)
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.
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.
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.