Title: Enable py launcher to launch repository Python.
Type: enhancement Stage: test needed
Components: Windows Versions: Python 3.10, Python 3.9, Python 3.8
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Franklin Yu, brett.cannon, eryksun, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2016-07-23 20:41 by terry.reedy, last changed 2021-03-20 22:08 by gregory.p.smith.

Messages (10)
msg271111 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-07-23 20:41
Running a repository build by typing a path such as
is tedious and error prone and I have to remember to omit '\win32' for 2.7 and it takes up much of a command line.

I would like to be able to run something like
  py -register 3.6r <path above>  # 'r' for repository, or possibly '+'
and subsequently have
  py -3.6r
launch the locally compiled but un-installed binary.  Possible?

I did not find 'py launcher' in Expert's Index or Components, so selected you two from memory and 'Windows'.  Please modify Components and Nosy as appropriate.  I have an impression that there is a launcher version for Mac but know nothing about it.
msg271113 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2016-07-23 21:18
This sounds like 2 related items (but I'm happy for them both to be under this issue, I'm not suggesting we need 2 issues):

1. Allowing py -register to add PEP 514 metadata to the registry for the given path.
2. Allowing py -<tag> to use PEP 514 metadata more generally, rather than its current explicit registry scan.

I'm OK with both of these in principle. I'd suggest that (1) register under HKEY_CURRENT_USER (so that it doesn't need elevation, and so it's a per-user setting) and that it uses the PythonCore "Company" value (as it's a core CPython facility).

We might need an "unregister" option as well, to avoid leaving clutter in the registry, and maybe even some means of listing what's been registered. That may be overkill, and manual registry tidy-up may be fine (but the same could be said of -register).

There are other considerations, too - this should probably be solely for interactive invocations. I assume you wouldn't expect to support shebang lines like "#!python3.6r"?

I'm not likely to have time to work on this myself in the short term (my C skills are a bit rusty, TBH) but I'm happy to review patches, etc.
msg271114 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2016-07-23 21:24
--register sounds interesting.  It could write to the user-specific py.ini, and would be useful for other things, like for `py --register pypy C:\pypy\pypy.exe`.  I've also thought it would be useful to be able to use py.exe directly to invoke interpreters configured in py.ini.
msg271115 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2016-07-23 22:01
> I assume you wouldn't expect to support shebang lines 
> like "#!python3.6r"?

That's already supported in py.ini in the [commands] section, per PEP 397. I've used this from Vinay's initial releases on Bitbucket, before the launcher was officially distributed with Python. 

One catch is that commands can't start with "python" because that's special-cased in the launcher. Instead you could use the following:


Then create a script with the shebang `#!rpython3.6 -i` that starts the REPL after it executes.

What's missing is a way to run custom commands directly from the py[w].exe command line. I wouldn't want to hog a letter such as "r" that a python.exe option could use someday (noting that command-line options can be combined like `-SORE`). But maybe it could use "--" or some other symbol to demarcate the command.
msg271116 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2016-07-23 22:17
On 23 July 2016 at 23:01, Eryk Sun <> wrote:
>> I assume you wouldn't expect to support shebang lines
>> like "#!python3.6r"?
> That's already supported in py.ini in the [commands] section, per PEP 397.

True, I'd forgotten that. I was meaning for interactive use, which as
you say isn't supported (I asked for it a long time back, but it was
rejected - maybe it's worth revisiting the idea, as I don't recall the
reason for the rejection).

Of course, having two places for launcher configuration, the registry
and the ini file, seems like it would be confusing. So that's an
argument for everything being controlled via the ini file. (BTW, the
documentation in doesn't
give much detail about what can go in the ini file, maybe that needs
msg271122 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-07-24 03:46
I think this is best written as:
* extend py.exe to handle PEP 514 properly
* write "PythonCore\dev36" (or equivalent - maybe "PythonDev\dev36"?) keys on each build

That way you could use "py -dev36" to get your latest build from source (actual tag open to bikeshedding).

Right now we write "python.bat" in the root of the source directory for the most recent build, so maybe that's a good enough workaround?

While I'd like to enable a "register" command, it's complicated enough and I suspect of limited value compared to directly editing the registry (or updating other interpreter's installers) that I'd rather not worry. A big part of the reason for PEP 514 is to be able to point other interpreters to it and say "do this and your users won't need to know where you installed everything".
msg271126 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-07-24 04:02
> having two places for launcher configuration, the registry and the ini file, seems like it would be confusing

My hope here is that the registry is "the place where all your Pythons are registered" and py.ini is "the place where settings for py.exe are kept".

By default (in time), py.exe will look through the registry at all your Pythons, but changes that should only affect py.exe go in its settings file.
msg329454 - (view) Author: Franklin Yu (Franklin Yu) Date: 2018-11-08 03:42
Any updates? I would like to switch between versions of PyPy.
msg388909 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2021-03-17 06:56
The narrow scope of this issue could be implemented by defining a scheme for local builds in the PythonCore key -- such as "X.Ys[-32]". The build process would create or update the "HKCU\Software\Python\PythonCore\X.Ys[-32]\InstallPath" key with the "ExecutablePath" and "WindowedExecutablePath" values. 

In PC/launcher.c, validate_version() would have to allow "s" after the major/minor version (e.g. "3s", "3.10s"), and locate_python() would have to ignore "s" when deciding to call get_configured_value(config_key) if no minor version is specified (e.g. for "3s", check PY_PYTHON3 and the "python3" value in py.ini).
msg389147 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2021-03-20 07:36
See also bpo-30405, which has more discussion about supporting PEP 514 in the launcher.
Date User Action Args
2021-03-20 22:08:40gregory.p.smithsetnosy: + brett.cannon
2021-03-20 07:36:01eryksunsetmessages: + msg389147
2021-03-17 06:56:44eryksunsetmessages: + msg388909
versions: + Python 3.8, Python 3.9, Python 3.10, - Python 3.6
2018-11-08 03:42:51Franklin Yusetnosy: + Franklin Yu
messages: + msg329454
2016-07-24 04:02:58steve.dowersetmessages: + msg271126
2016-07-24 03:46:39steve.dowersetmessages: + msg271122
2016-07-23 22:17:28paul.mooresetmessages: + msg271116
2016-07-23 22:01:11eryksunsetnosy: + eryksun
messages: + msg271115
2016-07-23 21:24:53zach.waresetmessages: + msg271114
2016-07-23 21:18:40paul.mooresetmessages: + msg271113
2016-07-23 20:41:39terry.reedycreate