[OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain

[Michael Torrie]

On 03/17/2015 02:39 AM, Steven D'Aprano wrote:
> On Tuesday 17 March 2015 12:46, Michael Torrie wrote:
> 
>> Python3 can be installed from Software Collections (and that is somewhat
>> reasonable), but it won't integrate by default, so you can't use
>> #!/usr/bin/python3 in your apps by default without altering the system
>> paths.
> 
> 
> If RedHat installs Python 3 in stupid places, that's a RedHat stupidity, not 
> a problem with package management.

Not quite.  When Python 3 is part of the standard repos, it goes in the
normal place and is in the path.

The point of Software Collections is to allow developers to play with
multiple versions of many kinds of software packages, some of which
overlap the system packages.  So Software Collections guarantees to
never conflict with the system versions of any of these things.  With
SCL I can install many versions of, say, Python 3 for testing purposes.

SCL was never intended to be a production model itself, near as I can
tell.  More of a playground for the developer.

> But, having said that, it's trivially easy to add /opt/python3 to your PATH, 
> or add a symlink from /usr/bin/python3 to wherever RH puts it. Is this 
> ideal? No, of course not. But it's hardly a road-block. It's not even a 
> barrier. It's barely a bump.

It is a barrier and a road block from a software distribution point of
view.  The solutions you offer are (manual tweaking of config files),
from a configuration management point of view, not too different from
compiling from source, which is not maintainable in any large-scale
server cluster.

Even for mere end users, it's not a very good model, depending on your
audience.  Sure we can blame the distro for not providing a decent
package.  But like Ben said, the conflict between the desire for
stability and the desire for the latest features often involves
difficult to solve contradictions.

> I think it's awfully precious to rule out using python3 for an application 
> because you need to make a couple of minor changes to the environment to 
> make it work. I guess that boils down to the difference between developers 
> who have the attitude "I'll just make it work, no matter what" and those 
> with the attitude "If everything in the environment isn't completely 
> perfect, no can do."

Not it's not precious at all.  If you are developing a large-scale
Django deployment, you're going to target versions that you know servers
support without any "minor changes to the environment."  Server space is
*very* conservative for good reason.  Every change has to be tracked so
it can be replicated and audited.  So we don't make random changes to
/etc/profile.  We don't install software from source generally, because
it would not be seen by the package manager, so security updates might
get missed.  It is a different world, at least when it's done right.

Like I say, starting with RHEL8, Python 3 will be the default, so we'll
likely see wider adoption by web apps using frameworks like Django.  And
Fedora has already designated Python 3 as the default Python for Fedora
22[1], so that means the transition is going to be more rapid.

[1] If they follow upstream advice, unlike Arch, /usr/bin/python will
still be Python 2 if the user specifically installs it from the
python2*.rpm packages.  The default Python packages will all be based on
Python 3, installed to /usr/bin/python3, and be installed by default.