[csw-maintainers] Support for multiple Python versions

[Maciej (Matchek) Blizinski]

I'm forking the conversation to a new thread.

No dia 14 de Outubro de 2010 21:40, Philip Brown <phil at bolthole.com> escreveu:
> On 10/14/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>> ...
>> If I have to choose between being consistent with how Perl is packaged
>> and how Python is packaged, I'd go with the latter.  I don't see any
>> real benefits for choosing the "one Python" strategy.  At the same
>> time, I see serious downsides.  For example, if you write any serious
>> Python code, you write it for a specific version, and you lock it down
>> to that Python version.  You might migrate it later on to a newer
>> version, but migration is a separate process.  You quite often need
>> Python 2.4 to run some scripts, and Python 2.6 to run others.
>
> That's..... kinda lame.
> if python was some small runtime library thingie like berkeleydb, I
> would just say okay fine. but python is a major set of packages.
>
> As a comparison... not that sun always does things right, but solaris
> 10, 2010 ships with one and only one version of python.
> (but a very old one. hrm.)

Hard to upgrade by replacing.  Would be easier with an overlap:
introduce the new one, build modules for it, then retire the old one
when the time comes.

> I think that, similar to ruby, we might be best served with a
> "primary" version of python, and then some "if you really need it"
> versions.
> primary version gets /opt/csw/lib/python or whatever.

Sure, that's not a problem.  It can be also driven by alternatives so
users have the choice.

> It should be pointed out that python, being interpreted, is different
> from the way we handle shared libraries.  There can be only one
> /opt/csw/bin/python. So in some ways, this is the most consistent
> thing to do.
> If we change /opt/csw/bin/python major version, then we SHOULD have to
> recompile everything, methinks.
>
> Does that make sense?

Partly yes - if we introduce a new version of Python, we need to build
all the modules for it.  In certain cases, it's necessary to pick
matching module versions, e.g. module foo in version 1.0 might be
compatible with Python 2.4 to 2.7, while module foo in version 2.0
might be compatible with Python 2.6 to 3.1.  In any case, each Python
version gets its own set of modules, and we need to build them.

However, this does not necessarily mean that we need to remove modules
for the old version of Python and its modules.  We can have
py26_twisted built for Python 2.6 and py27_twisted built for Python
2.7, happily living together in one file system.

> I'll also mention, that if we keep most things in /opt/csw/lib/python,
> then a new version of /opt/csw/bin/python, can and should
> automatically recompile everthing present there.
> (that's the benefit of the unified no-number directory)
> So for anything written portably, a version upgrade could be quite transparent.

The argument here is that you can keep old modules and use them for
the newer version of Python.  While it is potentially possible, not
all modules or programs will work well with a newer version.  Usually,
after a new version is released, other projects are catching up to
stamp out any compatibility issues.  We might get away with leaving
2.6 modules and using them for 2.7, but not with 3.1.

In the meantime, I've built Python 3.1 to try it out.  It passed the
smoke test: can be installed alongside Python 2.6, with both 2.6 and
3.1 versions working fine.

If anyone is interested in testing and/or reviewing, here are the packages:
http://buildfarm.opencsw.org/experimental.html#python-3.1

Maciej