On 2 September 2016 at 02:29, Avram Lubkin <av...@rockhopper.net> wrote: > On Thu, Sep 1, 2016 at 10:22 AM, Petr Viktorin <pvikt...@redhat.com> wrote: >> >> >> Whatever we do, I'd like it to be coordinated across multiple >> distrubutions, and blesed by a PEP like [PEP 394]. We don't want a solution >> specific to Fedora.
We do need to figure out the scope of what would be acceptable within the context of Fedora though - otherwise we could reach consensus upstream on Python's linux-sig, and then find we couldn't get the proposal through FESCo downstream. > I think the best way to serve the end-user is to manage /usr.bin/python with > alternatives, with slave entries for idle, pydoc, python-config, and the > python man page. This is compliant with the suggestions of the PEP and gives > control to the user. The symlinks should point to the major version > links/files as minor versions may introduce too many issues to address at > the moment. Summarising my longer reply to your other email about this, I think alternatives is a good fallback position that should be acceptable cross-distro if we can't come up with (and agree on) anything better. Unfortunately, alternatives doesn't actually meet the user needs we've had described upstream, which requests the ability to do *per-user* selective upgrades, allowing admins to initially restrict deployment of "Python 3 as default" to users that they're pretty sure can cope with the possible resulting incompatibilities without too much handholding, and then progressively roll it out to more users over time as the compatibility issues get ironed out for their particular environment. There's also clear migration value in allowing administrators to say "These particular service accounts still need to live in a Python 2 only world, blissfully unaware that Python 3 is even a thing", and then whittle those away over time, rather than needing to migrate all their custom admin scripts before even one user gets upgraded to Python 3 as their default Python. Putting it like that though, perhaps an upstream proposal for multi-tier configurability support would make sense? * Tier 0: "the default Python" is determined at the distribution level. For the majority of current distributions, that means Python 2, but on a select few it means Python 3. * Tier 1: "the default Python" is configurable on a per-system level. Distros pursuing this option (e.g. by moving /usr/bin/python under 'alternatives') are still advised to keep the out-of-the-box default as Python 2. This will be sufficient for at least some environments to start managed migrations from Python-2-as-default to Python-3-as-default, and further establishes the precedent that "/usr/bin/python will always be Python 2" is an incorrect assumption. * Tier 2: "the default Python" is configurable on a per-user level. Sufficiently determined sysadmins can actually configure this today, so it would mainly be a matter of looking at what's involved in doing that, and making it simpler for people to set up. * Tier 3 (highly experimental): "the default Python" is configurable on a per-script level, using something like pythonmux. If we pitched something like that, then rather than distros having to agree on which level of configurability was appropriate, we'd just have to agree on "if we implement that tier, we're happy to abide by those guidelines", and then it would be up to individual distros to decide which level of configurability they wanted to offer (and they may make different choices when it came to interactive use vs non-interactive use). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
