For the values of some of the keys, it would make sense to map them to PEP 496 identifiers. It would be odd if the values in the registry differed from the equivalent in the pep about environment markers.

If the registry had a standardised list of key names for all environment markers, non-python (native) apps could implement pep 496 mini language to download and install an appropriate wheel into a user selected environment that provided values for those keys, without needing to invoke the python interpreter for that environment. It might also need to know where to put the package, but that can be derived from platform_python_implementation and specified in a separate pep.

Rather than use virtualenv to think about this pep as an example use, even implicitly, a better example might be pyenv which attempts to do the same without invoking python wherever possible. Theoretically it could be ported to a bash on windows with a few gnu binaries added.

If the registry had a standardised list of key names for all environment markers, non-python (native) apps could implement pep 496 mini language to download and install an appropriate wheel into a user selected environment that provided values for those keys, without needing to invoke the python interpreter for that environment.

Thanks. This is a good example of a non-IDE use case.

a better example might be pyenv

I guess the key point here is pyenv versions which lists the available versions to select from. I don't know where the Unix pyenv gets its version names from, but the list shown in the example screenshot on the page you linked to:

2.7.10
3.5.0
miniconda3-3.16.0
pypy-2.6.0

is the sort of naming I'd expect in a command line utility (as opposed to the ExampleCorp\distro-3 style, with no explicit version, that the PEP is currently implying).

The names are defined by the filenames in https://github.com/yyuu/pyenv/tree/master/plugins/python-build/share/python-build

OK, cool, so by pyvenv itself. That's similar to my thought about a "short alias to Company/Key mapping", and so tends to imply that it's not actually unreasonable for tools to manage their own short names.

I'm becoming more and more inclined not to worry about getting hung up on the format of "Company" and "Key", beyond saying that we recommend human-readable, short, descriptive values, and I'd like to establish the principle that Key should typically be a version. Ideally the PythonCore values should provide the example to follow - I'm just a little concerned that the PEP examples imply "anything goes" a bit too much.

I would rather Key not include a specific version unless it can be installed side-by-side with others. e.g. miniconda3 is sufficient, because nobody should have miniconda3-3.16.0 and miniconda3-3.17.0 simultaneously. We don't have PythonCore\3.5.1 and PythonCore\3.5.2 - it's just 3.5.

Not sure if it was missed (or if I edited it out), but I suggested at one point that tools like pyenv/virtualenv should probably allow use of just the Tag to identify an installation when it's unambiguous. So given:

PythonCore\2.7
PythonCore\3.5
WinPython\3.5
Continuum\anaconda3

You could do:

virtualenv -p 2.7
# success!

virtualenv -p anaconda3
# success!

virtualenv -p 3.5
# failure, probably with a printout of
Did you mean:
  PythonCore\3.5
  WinPython\3.5

I could add this as an example, but I'm really hesitant to add anything that appears to dictate UI. If a tool wants to resolve in some other way, that's up to them and their users (bearing in mind that most tools will be internal to various companies and never see the light of day).

I'm +0 right now on adding an "Illustrative Examples" section, both with some registry layouts and code for reading them (and also a GetBinaryType call to handle 32-bit vs 64-bit detection without running the interpreter).

My main hesitation is that I don't want examples to become binding (i.e. "you're only valid if the code in the PEP displays everything"), especially since (by design), practically everything in the PEP is optional.

OK. Thanks for the updates and clarifications. I think they help a lot.

I don't honestly think there's much problem with adding examples, and I think it would help a lot. By all means add a disclaimer that the example code is for illustration only. I do think that an example should cater for missing data (run the interpreter -> look for the ExecutablePath value, if not, try InstallPath\python.exe, but allow for that exe not to exist), as IMO an example that shows what proper error handling looks like will stop people from making unwarranted assumptions in their production code. (If the resulting example is ugly and over-complex, that may say something about the spec, of course :-)) Personally, I'd like to see some code in here.

At the moment, I'd characterise this PEP as doing a few things:

1. Giving a clear message to non-python.org distributions that they should not use our registry space, and providing an alternative for them,
2. Agreeing the basic Company\Key structure for finding sys.prefix.
3. Suggesting some informational data that distributions can optionally supply, and tools can optionally use (the intended use being for information display, likely in a GUI).
4. Providing a little more detail on historically how the python.org installers used the registry.

Within that scope, I'm happy with the PEP. I think I initially expected more from it - and I still think it's a shame that it doesn't go further in terms of "introspection without needing to run the interpreter" - but it achieves the above goals, which is great.

If you can decide on whether you're willing to add the example code, then I think we're there. I'll post a last call for comments on python-dev, for people who haven't been following the tracker discussion, and then we can sign this off.

Added hopefully the final textual clarifications and the first example. It's a shame that dealing with the registry is so messy in Python - there's far more indentation there than I'd like, and it doesn't even include the backwards compatibility handling or most of the metadata.

Will try and get to a couple more examples over the coming week, but wanted to push it online in case I change machine before I next get a chance to work on it.

Thanks! This looks pretty good now. Once you've completed the changes you want to make, I'm happy to sign this off (on a procedural note, I'm not sure if it needs a posting of the final version to python-dev, or if we can just refer back to here. I'll check on that.)

I just finished another couple of examples, including the values that will be written for a 3.6 install (once the PEP is accepted and I update the installer, that is).

I think we should merge the changes and post one more time on python-dev. That way we'll have the mailing list trail of acceptance and I can do the final update here with the usual links.

Sounds fine to me. Let's do that and unless anyone comes up with a last-minute objection (!), I'll formally accept the PEP on python-dev.

I'm also in the process of posting a note to python-committers suggesting that we update PEP 1 to cover this process, so it's formally documented.