[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)

Um, the PEP has "Unix-Like Systems" in its heading, so discussing the
Windows situation seems out of scope to me.

You're one of its authors, so if you really want to keep the paragraph
about the anticipated unified future we can keep it (though preferably this
should be discussed in the issue, https://github.com/python/peps/pull/630).
But I think this PEP is strongest in its guidelines for what distros and
sysadmins should do *today*; I feel that that paragraph encourages hopes
about a future that's farther away than most people care to plan, and not
at all certain.

On Fri, Apr 27, 2018 at 6:23 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 28 April 2018 at 01:37, Petr Viktorin <encukou at gmail.com> wrote:
>> Hello,
>> After discussion on the [Pull Request], my update to PEP 394 changed
>> scope somewhat. The new major changes are:
>> - The `python` command may not exist at all in some cases (see the PEP
>> for details)
>> - The paragraph about the anticipated future where python points to
>> Python 3 is removed. (We'd rather see a future where `python` doesn't exist
>> and one always has to specify `python2` or `python3`.)
> That isn't currently *my* desired future, as I don't want to see a python3
> to python4 naming transition at any point, I want a transition from python3
> back to an unqualified name to accurately reflect the change in version
> management philosophy resulting from the extended Python 3 migration. (And
> then "python3" would linger solely as a backwards compatibility remnant,
> even if it referred to python 4+, or a switch to some kind of CalVer based
> versioning scheme)
> However, it may be possible to solve two problems at once here, as one of
> the issues we have in writing cross-platform instructions for both Windows
> and *nix systems is that "python" isn't guaranteed to be on the Windows
> path, but the "py" launcher *is*. This means the most robust tooling
> invocations on Windows are of the form "py -m pip ...", since they don't
> care about how your system PATH is configured. Getting not only "python",
> but also scripts installed with "py -m pip install --user..." to be
> reliably on the PATH is an arcane problem with assorted complications
> stemming from the differences between per-machine and per-user
> installations of Windows applications, and the "py -m module ..." approach
> avoids that mess entirely (as long as the tools of interest correctly
> support invocation via "-m").
> The downside of those instructions is that it means we have a platform
> split where, depending on how your system is setup, which version of Python
> you're using, and whether or not you're running in a virtual environment,
> you need to invoke Python from the command line as one of:
> - python
> - python3
> - py
> (more details at https://github.com/pypa/python-packaging-user-guide/
> issues/396 )
> Thanks for everyone involved, especially Guido for pitching in with the
>> intended direction -- which was not clear from (or is genuinely different
>> from) the 7-year-old PEP!
> It's a change, and not one that's been explicitly discussed with the
> current authors of the PEP yet (although I do see that Barry has chimed in
> on the PR).
> I think it's a reasonable way for us to go, *if* it's accompanied by an
> explicit decision that we want to drive cross-platform convergence around
> "py" as the convention for unqualified version independent access to a
> Python interpreter (regardless of whether or not a virtual environment is
> active or not)
> The key missing piece for doing that would be to define how we'd want a
> `py` launcher to work on *nix systems, and then provide that as part of
> CPython 3.8+ (and potentially backport it to a 3.7x maintenance release).
> Cheers,
> Nick.
> P.S. Note that on Windows, `py` always refers specifically to the launcher
> (it doesn't get shadowed in virtual environments), but the launcher itself
> is virtual environment aware (see https://www.python.org/dev/
> peps/pep-0486/ for details).
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org

--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180427/170ba1d6/attachment-0001.html>