[issue44982] Add vendor information

[Filipe Laíns]

Filipe Laíns  added the comment:

> 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44982] Add vendor information

[Matthias Klose]

Matthias Klose  added the comment:

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.

--
nosy: +Marcus.Smith, dstufft, ncoghlan, paul.moore, pradyunsg

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44982] Add vendor information

[Filipe Laíns]

New submission from Filipe Laíns :

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.
>>>

--
messages: 400135
nosy: FFY00, christian.heimes, doko, jaraco, steve.dower, willingc
priority: normal
severity: normal
status: open
title: Add vendor information
type: enhancement
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com