On 04/27/18 02:03, Ben Finney wrote:
Ben Finney
writes: Petr Viktorin
writes: […] we feel that the only way to *enforce* that guidelines is to provide environments where the `python` command does not work (unless explicitly installed).
Yes. The ‘python’ command is confusing, for the reasons you say. There should be ‘python2’ and ‘python3’ commands for Python 2 and Python 3 respectively, and no ‘python’ command should be installed by the operating system.
The fact that ‘/usr/bin/python’ exists is an historical accident, and I agree with the proposal you state: the best way to correct the confusion is to bar the confusing command from being installed by packages.
Because the above is ambiguous, I'll clarify: I am not calling for, and PEP 394 does not call for, the banishment of the ‘python’ command.
Well, Guido *is* calling for it :) It would break too many things, but after discussions on the PR, it's clear that we want a future where the "python" doesn't exist. But while it's available, it should point to Python 2.
What I'm saying is that muddying the rules further on what ‘python’ may or may not mean is *worse than* banishing the ‘python’ command entirely.
That's also consistent with the PR discussion. (But not that much with the original PEP, which said `python` is expected to eventually mean `python3`.)
So, short of banishing ‘python’ entirely, I think PEP 394 is already a good clear way to address the issue. Existing, documented and supported means to locally modify a ‘python’ command already exist and should be sufficient.
I trust that PEP 394 will not be weakened in its effect, and I wish you well with using the already-supported, already-documented, PEP-394 compatible means to add local customisations for a ‘python’ command.
Right. But some already-supported, already-documented mechanisms like Debian Alternatives or alternate package repos, are not compatible with PEP 394. And as a PEP 394 compliant distro, we also won't be promoting the /usr/local or $HOME/bin ways to change `python` (which makes me a bit sad, because that documentation might have included a link to the caveats listed in the PEP).