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 <[email protected]> <http://bugs.python.org/issue30405> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
