On 3 September 2016 at 14:32, Nick Coghlan <ncogh...@gmail.com> wrote: > 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. >
So the general way that 'configurable on per-user level' would be to put to put links in a directory that over-rode the system path files.. eg ~/.userdefined_bin/:/usr/bin:/usr/local/bin:~/bin This has generally been considered a security problem in that anything dropped in ~/.userdefined_bin can override defaults without the user knowing it. [The old ~/.userdefined_bin/mv -> /usr/bin/rm or a script which is called ls and then rms the files after showing them.] However I think we are in a world of such security nightmares just from the browser being used that this is just par for the course. > * 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 -- Stephen J Smoogen. _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
