This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients eryksun, ezio.melotti, paul.moore, steve.dower, terry.reedy, tim.golden, vstinner, zach.ware
Date 2017-05-23.05:00:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1495515651.01.0.289967330252.issue30405@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2017-05-23 05:00:51eryksunsetrecipients: + eryksun, terry.reedy, paul.moore, vstinner, tim.golden, ezio.melotti, zach.ware, steve.dower
2017-05-23 05:00:51eryksunsetmessageid: <1495515651.01.0.289967330252.issue30405@psf.upfronthosting.co.za>
2017-05-23 05:00:51eryksunlinkissue30405 messages
2017-05-23 05:00:50eryksuncreate