What information do you gather for interpreters and environments?

[brettcannon]

@CAM-Gerlach

Environment name is still a bit of a problem, since we’d have to include hacky, fragile and limited heuristics based on the path (same as we do now) to handle this, since AFAIK there isn’t a way to reliably query this from within Python.

You can get it from pyvenv.cfg, but I also don’t view that information as critical to using an environment as much as a nice-to-have (we have found giving users the stem of the directory that a virtual environment is contained in works well enough when a prompt was not specified).

@CAM-Gerlach

having an environment activated or somewhere on the path of the calling editor/IDE (Spyder is itself written in Python, and can run from a variety of environments, but we still need the info on all the user’s envs) isn’t going to interfere with the information above being provided about the others, right?

Not the way I have things in my head. There’s a --list option to the Python Launcher for this sort of thing. Once again, you’re getting ahead of me. Right now I’m just focusing on the data aspect and not on the plug-in/finder/searcher/discovery aspect.

@CAM-Gerlach

At least for us, no, though I suppose theoretically it could be useful to tools interested in low-level details of things like word sizes that don’t want to parse a potentially arbitrary architecture string to infer this.

@steve.dower

Wouldn’t have thought so. It will only tempt people to encode choices based on something that’s probably wrong. I can’t think of anything that would only depend on machine word size but not actual platform on my own machine .

OK, it sounds like no one can think of a reason to break it out if we include CPU architecture, so I’ll just make it a single thing.

@steve.dower

We do need a better way to expose the expected/emulated platform from inside CPython, because right now it doesn’t. Just providing what packaging.tags would generate by default might be a good option?

I think what you’re after I have discussed in What information is needed to choose the right dependency (file) for a platform? . I didn’t think about including the relevant platform info here to create a lock file from a set of requirements, but if we view this as a data format for exchanging interpreter/environment info then I can see it making sense to include it here.