Has Red Hat helped or hurt?

[John Baxter]

In article <4pbhdu4t69e6eqt3q3l4q72odo0c9ufo9p at 4ax.com>,
 Tim Roberts <timr at probo.com> wrote:

> Red Hat 7.x uses Python 1.52 for many of its configuration and
> administration activities.  Ordinarily, I'd say this was a Good Thing for
> the betterment and furtherance of Python.

On balance it is, despite the 1.5.2-ishness.

> 
> However, it makes it deucedly difficult to upgrade away from 1.52.  If one
> upgrades /usr/bin/python to be 2.x, all of Red Hat's custom configuration
> scripts are no longer found in site-packages.
> 
> How have other people handled this?  Do you just copy all of
> 1.52/site-packages to 2.x/site-packages?  Do you install Python 2.x into a
> separate directory and grumble every time you have to change the #! line in
> your scripts?  I tried updating all of the #! lines in the Red Hat scripts,
> but this, of course, blows as soon as you do an rpm upgrade of a
> Python-based package.

1.  Leave Python 1.5.2 alone as Red Hat ships it.  Leave the command 
name python pointing to 1.5.2

2.  Install Python (whatever) "beside" 1.5.2.

3.  Develop some convention for the command name...we're using #! lines 
like

#!/usr/bin/env python-historic

to get 1.5.2

and
#!/usr/bin/env python-preferred

to get our current Python-of-Choice


(We'll probably have to invent python-future or python-next or something 
sooner or later.)

(Things are placed so that env finds what it should find even with the 
minimal PATH from cron...and we don't run anything which doesn't have 
/usr/bin/env, but not because of that lack.  Won't work for people who 
can't say that.)

This won't be fixed in RedHat until they decide to call something Red 
Hat 8 (which I hope goes better than 7.0 did).  They didn't upgrade at 
7.0 time because they had used the rand module without having noticed 
that it was deprecated when they used it, so its lack broke their tools.  
Sigh!  But by now RH would have an old Python even if they had gone with 
what was current.

  --John