PEP 514 provides a way for installed Python interpreter to specify the name of the entity which compiled and distributed that interpreter along with a URL back to that distributor. For instance, on Ubuntu, Canonical would list itself as the distributor for the version that comes from them, but Deadsnakes could list themselves for their builds of Python. Same for Homebrew vs Apple (if the latter was still distributing Python). Pyodide could list themselves as the distributor. Same goes for pyenv.
I would envision this being controlled via a ./configure flag, so setting it wouldn’t be cumbersome.
The API would probably be:
name: name of the distributor.
url: the URL back to the distributor, perhaps to where to get that distribution.
This seems like a gap in information about the Python interpreter that you’re running that you can’t get from sys itself that can be useful for identifying an interpreter.
For what its worth, I had a need for this just a couple days ago when helping a user debug a problem, to track down what Python they were using and from where that they had a problem on, which is not uncommon. Right now this sort of information (and a bunch more) is typically printed at interpreter startup, e.g. for Anaconda,
Python 3.9.7 | packaged by conda-forge | (default, Sep 29 2021, 19:15:42) [MSC v.1916 64 bit (AMD64)] on win32
but I wasn’t sure of an easy programmatic way of telling users to get at it, either from Python or the shell, and this of course can presumably be customized to anything, or not, with no standard format.
The general idea seems good, but the details may need tweaking.
Is this a build-time setting? What if I re-distribute a Python built elsewhere? How about tools that wrap Python into a .exe or equivalent frozen executable?
Is this important enough to be built-in to sys, or could it go into the platform module?
I feel that in practice, there may not be one distributor:
I distribute a flatpak or snap application;
which uses Python supplied by some third-party source;
which gets Python from some distro, like Linux Mint;
which tweaks the Python from another distro, like Ubuntu;
It’s easy. I can either add the values to pyconfig.h or to Makefile and pass it as -D to a build target.
It is usually trivial to find the download URL for a distro. It would be more useful to include a link to the downstream build instructions and patches to see how Python was modified and built by a vendor. For deadsnakes the URL could point to the Launchpad PPA. For Fedora it could link to the COPR or Fedora source dist-git.
Just a quick +1 from my perspective. Currently, ActiveState will change the header printed at the interactive interpreter, as Anaconda and others do. Having a one-liner universal python command our customers could run to determine where they got a particular interpreter from would possibly cut down on a lot of confusion or us supplying custom scripts to do similar.
That’s your call, but I assume you wouldn’t change it since what the “distribution” is didn’t change, you just gave the same file to someone else.
If they built Python or messed with what got distributed with it, I would think they should update it. Otherwise it’s left.
It’s an open question.
I can see the url part being documented as, “more information about the distribution.” How that gets interpreted or is the best use I think is up to the distributor.
Anaconda and ActiveState are perfect examples of folks I know who would benefit from this and are a target user of the setting. I will also say we run into support issues in VS Code where people run into weird bugs and it often turns out to be some custom build, but it takes a while to find that fact out.