[issue30405] build.bat: register binaries for py launcher

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30405] build.bat: register binaries for py launcher

[Eryk Sun]

Change by Eryk Sun :


--
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30405] build.bat: register binaries for py launcher

[Eryk Sun]

Change by Eryk Sun :


--
Removed message: https://bugs.python.org/msg293989

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30405] build.bat: register binaries for py launcher

[Steve Dower]

Steve Dower added the comment:

> Steve, I gather you don't think it's a problem to use arbitrarily named tags 
> on the command line. The launcher shouldn't look for an "h" tag for `py -h`

Sure, we can reserve some tags - the -x/y syntax would let you refer to a 
conflicting one. But other than PythonCore\x.y for (x, y) <= (3, 4), there 
shouldn't be any need for version or binary checks. Those were needed because 
we didn't write correct tags, but as of Python 3.5 we write good tags and PEP 
514 essentially requires it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30405] build.bat: register binaries for py launcher

[Eryk Sun]

Eryk Sun added the comment:

The existing code can be adapted to generalize support for version-number tags, 
i.e. X.Y[-32|-64]. locate_all_pythons() would need to search every company key 
to add executable installations that use version-number tags to the 
installed_pythons array. Whether a tag uses a -32 or -64 suffix is immaterial 
because the launcher calls GetBinaryType on the executable. A "Company" field 
would be needed in INSTALLED_PYTHON to allow narrowing a search, such as `py 
PythonCore\3.6-32`. Also, compare_pythons() would need to order PythonCore 
ahead of other companies in the installed_pythons array to meet the precedence 
requirement. 

A new find_python_by_tag(tag, company) function could implement finding 
non-version tags. It would return the first executable Python installation that 
exactly matches the tag. find_python_by_tag() would be called in process() in 
between validate_version() failing and skipping past the command-line options.

(BTW, skipping past the options doesn't work right for options that take an 
argument such as -X and -W. The launcher sees the optional argument as the 
script. At best the _wfopen_s call fails, and then it falls back on executing 
the default Python.)

It's conceivable to generalize maybe_handle_shebang and parse_shebang to 
support companies in virtual shebangs such as #!/usr/bin/ExampleCorp/python3.6, 
but that's beyond the intention of the built-in virtual shebangs. They were 
added to support Unix shebangs in cross-platform scripts. Defining custom 
commands in py.ini would be a better approach for something like this.

Steve, I gather you don't think it's a problem to use arbitrarily named tags on 
the command line. The launcher shouldn't look for an "h" tag for `py -h`, so 
how about using a list of existing command-line options that will never be 
looked up as unqualified tag names (i.e without a company)? In that case such 
names would need to be used in -Company\Tag form.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30405] build.bat: register binaries for py launcher

[Steve Dower]

Steve Dower added the comment:

My thinking was basically to use an algorithm like this:

if sys.argv[1].startswith('-'):
company, _, tag = sys.argv[1][1:].rpartition('\')
if company:
# look for Tag under Company
else:
# look for tag under PythonCore, then other companies

We'd need special handling for Python versions before 3.5 (because of the "-32" 
change), and possibly for the "-64" suffix as well. But in general, for unique 
tags you should only have to specify the tag, and the company is used to 
disambiguate/filter if desired.

SysVersion/SysArchitecture/Version are purely informational according to the 
PEP (and certainly by intent, if the wording happens to be unclear).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30405] build.bat: register binaries for py launcher

[Eryk Sun]

Eryk Sun added the comment:

Supporting PEP 514 tags is an interesting idea, but maybe you could go into 
more detail about what you have in mind. Are you thinking of using the 
SysVersion, SysArchitecture, and [Windowed]ExecutablePath fields where 
available instead of parsing version tags and assuming "python[w]/exe"? How 
would the expansion of candidate installations affect virtual "python" shebangs 
and command-line arguments such as -3.6-32? If there are several 32-bit 3.6 
installations, which one wins?

The PY_PYTHON environment variable could support qualified tags such as 
"PythonDev/3.6-32". However, arbitrarily named tags can't be supported on the 
command line without introducing an option reserved for the launcher. It could 
look for an `X PY_PYTHON` option such as `py -X PY_PYTHON=PythonDev/3.6-32`. 
That's a bit verbose, but simpler than `cmd /c "set PY_PYTHON=PythonDev/3.6-32 
& py`.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30405] build.bat: register binaries for py launcher

[Steve Dower]

Steve Dower added the comment:

I am most interested in making py.exe follow PEP 514 and look up tags. Given 
this, we could register builds as "PythonCore\Dev" and then use "py.exe -dev" 
to run the most recent build. At worst, we only have one lingering registration 
(and a positive - it would be available to any tools that follow PEP 514 to 
locate Python installs).

Alternatively, it could go to "PythonDev\..." and we have another way to look 
it up.

The default tags used to register Python deliberately match the py.exe launcher 
(e.g. "3.6" and "3.6-32", though it now also supports "3.6-64" to prevent 
fallback to the 32-bit interpreter). This should make it *nearly* a non-issue 
to change the launcher to look up Tags rather than versions. Probably needs a 
prototype to see just how bad it would be - I haven't had time to do it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30405] build.bat: register binaries for py launcher

[Terry J. Reedy]

Terry J. Reedy added the comment:

>From a couple of tests, the local python.bat should be satisfactory for most 
>of my current uses.  Being part of a #30362 listing would be nice, but I don't 
>often change my set of build binaries.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30405] build.bat: register binaries for py launcher

[Eryk Sun]

Eryk Sun added the comment:

The launcher could be extended to support additional suffixes in the version 
string. Currently -32 is supported after the minor version number (e.g. 
3.6-32), and (per a recent update) the latest version of the launcher will also 
support -64, with and without specifying the minor version number. This could 
be extended to support specifying an [o]fficial / [s]ource and [r]elease / 
[d]ebug build. A debug build wouldn't be separately registered on the system 
since it coexists with the release build. Instead, "d" would force the launcher 
to look for python_d.exe instead of python.exe. A default search would prefer 
an official build over a source build and a release build over a debug build. 
The point of supporting "o" and "r" suffixes is to force an error if an 
official/release build isn't available, rather than defaulting to a 
source/debug build. 

Under the hood, the INSTALLED_PYTHON struct would be extended with source_build 
and debug_build boolean values in addition to the bits value (which is an int 
but may as well be boolean). So there are up to 8 possibilities for every minor 
version number. MAX_INSTALLED_PYTHONS shouldn't have to be increased from 100. 

For example, `py -3-32d` would look for the highest 3.x 32-bit debug build and 
prefer an official build over a source build. `py -3-32od` would narrow the 
search to only official builds. `py -3-32sd` would instead narrow it to only 
source builds. In the latter case, the registry key would be named like 
"3.7-32s" to distinguish it from an official install. A build process with 
admin privileges would register the build in HKLM (taking care to create a 
"-32" key using KEY_WOW64_32KEY). Otherwise use HKCU.

For convenience, build.bat could set PY_PYTHON after a successful build, to 
make the current source build the default for the command-line and virtual 
shebangs, e.g. `set PY_PYTHON=3.7sd` for a registered 64-bit debug build. This 
would have to be executed after an endlocal statement, since it does most of 
its work in a setlocal block.

--
components: +Windows -Unicode
nosy: +eryksun
title: PCbuild.bat: register binaries for py launcher -> build.bat: register 
binaries for py launcher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com