PEP 394 update proposal: Allow changing the `python` command in,some cases

[Petr Viktorin]

Hello,

Upstream I submitted a [change to PEP 394] to allow distributions to 
change /usr/bin/python in some limited cases:

- Users and administrators can, by a deliberate action, change python to 
invoke Python 3. (Activating a venv counts as such an action, but so 
would e.g. using alternates, installing a non-default overriding 
package, or replacing /usr/bin/python.)
- In controlled environments where being explicit is valued more than 
user experience (test environments, build systems, etc.), distributions 
can omit the python command even when python2 is installed.

If this goes through, in Fedora I would like to:

- Create a "python" package containing *just* the /usr/bin/python 
symlink. This would be a subpackage of python2, and python2 would 
*suggest* it. In other words, it would be installed by default with 
Python 2, but mock, koji, and test tools would omit it (unless something 
deliberately Requires `python` or `/usr/bin/python`).

- Put an unofficial "python 3.6" on COPR (and maybe eventually in a 
Module), which would be the recommended way to make `python` invoke 
Python 3.


[change to PEP 394]: https://github.com/python/peps/pull/630
Upstream post on python-dev: 
https://mail.python.org/pipermail/python-dev/2018-April/153042.html


Let me know what you think.

[Nick Coghlan]

On 26 April 2018 at 05:22, Petr Viktorin <pviktori(a)redhat.com&gt; wrote:
>  If this goes through, in Fedora I would like to:
>
>  - Create a "python" package containing *just* the /usr/bin/python symlink.
>  This would be a subpackage of python2, and python2 would *suggest* it. In
>  other words, it would be installed by default with Python 2, but mock, koji,
>  and test tools would omit it (unless something deliberately Requires
>  `python` or `/usr/bin/python`).
>
>  - Put an unofficial "python 3.6" on COPR (and maybe eventually in a Module),
>  which would be the recommended way to make `python` invoke Python 3. 
Cool, thanks for moving this forward!

Did you want to update
https://fedora-python.readthedocs.io/en/latest/plans/default-python-module/
accordingly, or should that entire site just be scrubbed as an
experimental idea that didn't work out in practice?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan(a)gmail.com   |   Brisbane, Australia

[Petr Viktorin]

On 04/26/18 09:17, Nick Coghlan wrote:
>  On 26 April 2018 at 05:22, Petr Viktorin <pviktori(a)redhat.com&gt;
> wrote:
> > If this goes through, in Fedora I would like to:
> >
> > - Create a "python" package containing *just* the /usr/bin/python symlink.
> > This would be a subpackage of python2, and python2 would *suggest* it. In
> > other words, it would be installed by default with Python 2, but mock, koji,
> > and test tools would omit it (unless something deliberately Requires
> > `python` or `/usr/bin/python`).
> >
> > - Put an unofficial "python 3.6" on COPR (and maybe eventually in a
> Module),
> > which would be the recommended way to make `python` invoke Python 3.
>  
>  Cool, thanks for moving this forward!
>  
>  Did you want to update
>  https://fedora-python.readthedocs.io/en/latest/plans/default-python-module/
>  accordingly, or should that entire site just be scrubbed as an
>  experimental idea that didn't work out in practice? 
The current discussions and documentation is scattered between there, 
the mailing list, Fedora Changes, the Wiki (for things that aren't 
Changes only because they affect multiple releases), the Fedora 
Developer Portal, etherpads and PEPs. It's all confusing, I'm afraid.

But no, I don't think the Sphinx site is working very well for design 
and development notes. Etherpads are easier to edit, the mailing list 
and Fedora changes/guidelines are good for rough and final drafts, and 
the Developer portal is for documentation – it's worse technically, but 
better in that it's not a Python-specific silo.
Pull request driven collaboration is great (after an initial draft 
phase), but when the results then need to be copied to mediawiki or 
markdown, it doesn't make much sense to bother with ReST :(