This is somewhat related, but also somewhat tangential to PEP 711: PyBI: a standard format for distributing Python Binaries . Over there, @njs is suggesting recording what is necessary to resolve dependencies for an interpreter (previous discussed in What information is needed to choose the right dependency (file) for a platform?). From the perspective of VS Code and the Python Launcher for Unix, I’m also interested in other details about the interpreter the help people understand what interpreter they are selecting and how to use the interpreter that can be recorded statically (i.e., what to show users in VS Code and how to execute their code).
I have been asked a few times to bring forward my thoughts on this here as I have a sketch of the details the Python Launcher for Unix and VS Code would be interested in at Support a way for other tools to assist in environment/interpreter discovery · brettcannon/python-launcher · Discussion #168 · GitHub . With PEP 711 probably about to spark some conversation, I figured now might be a good time to discuss this and see if there’s any chance of getting a unified set of data that we could record about an interpreter so we can get some interoperability around it for tools (both producers and consumers of it).
For ease of reading, my proposal of interpreter details is outlined by the following:
// Returning an array forces the details to be fully self-contained. This facilitates any library that
// may return a collection of these results by not requiring any post-processing on what a locator
// returns; chaining results from multiple sources is all that is required.
[
{
// A unique identifier for the interpreter.
// The key should be unambiguous but as weakly specified as possible, i.e. to the
// directory for environments, but to the specific interpreter for something found on `PATH`
// (i.e. `python3.11`, not just `python3`). That way tools can generally agree on the same key
// w/o coordination. (Open question whether this should be to the most specific path instead.)
"path_id": "/home/brett/my-venvs/my-venv",
"python_version": {
// `sys.version_info`
"major": 3, // Optional
"minor": 10, // Optional
"micro": 1, // Optional
"releaselevel": "final", // Optional
"serial": 0 // Optional
},
"implementation": { // Optional
// `sys.implementation`
"name": "cpython",
"version": { // Has the same structure as `python_version` above.
"major": 3, // Optional
"minor": 10, // Optional
"micro": 1, // Optional
"releaselevel": "final", // Optional
"serial": 0 // Optional
}
},
"executable": {
// An array specifying what is required to execute the interpreter.
// Expectation is to append args to code to the end of the array before
// execution.
// E.g. for conda environments:
// ```
// ["/path/to/conda", "run", "--path",
// "/home/brett/.conda/envs/conda-env", "--no-capture-output"]
// ```.
"run": [
"/home/brett/my-venvs/my-venv/bin/python3.10"
],
"bits": 64, // Optional
"architecture": "x86-64" // Optional
},
"environment": { // Optional
// What type of environment, e.g. "virtual", "conda", etc.
"type": "virtual",
"name": "my-venv" // Assume the directory if no specific name.
},
// Is the result specific to the workspace?
"context-sensitive": true,
// Who created this result.
"locator_name": "Python Launcher" // Optional (?)
}
]
All the data related to the interpreter should be retrievable if some code was run. Everything is optional so that as much data can be provided quickly, but then potentially filled in later if needed (e.g., the Python Launcher technically just cares about executable.run, while the version details are simply helpful in making better decisions).
Adding in packaging details wouldn’t be hard and could make sense, but since I started from the perspective of execution and display details I didn’t worry about that (yet). Plus I figured it could be added later as more optional data.
I will say that if this data every ships with every Python interpreter and can simply be read from a file that would be amazing for my use cases.
what makes them special?
