[csw-maintainers] Python 2.7

[Maciej (Matchek) Bliziński]

2013/7/23 Peter FELECAN <pfelecan at opencsw.org>:
> "Maciej (Matchek) Bliziński" <maciej at opencsw.org> writes:
>
>> 2013/7/22 Peter FELECAN <pfelecan at opencsw.org>:
>>> Do you mind committing the patch that you proposed in [1] with the
>>> exception of different naming schemes for 2.7, i.e. no CSWpy27- prefix?
>>
>> The naming remains a problem, if we want to share modules between 2.6
>> and 2.7, we need to do something similar to what Debian did.
>
> Lets do it Debian way. Always a good reference, as you already
> mentioned:
> http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html

This document doesn't say too much about what they do to share python
modules, it only mentions /usr/share/pyshared in one place without
providing any details. I'll return to this later in the email.

>>> What about CSWpython27 and co: do yo release them?
>>
>> I've switched both Python versions to alternatives, so we're ready to
>> release them. The main problem to solve is how do we share modules
>> between 2.6 and 2.7.
>
> My question is: do you release 2.7?

I'm pushing 2.7 out to unstable right now.

>> As to why 2.6 code wouldn't work in 2.7 ‒ Python 2.7 is meant to be
>> backwards compatible, so there isn't an obvious example. In a perfect
>> world you'd just flip the switch, but in reality you cannot migrate
>> your production over to 2.7 without prior testing and a migration
>> procedure. The migration procedure would include changing
>> #!/opt/csw/bin/python2.6 to #!/opt/csw/bin/python2.7.
>
> From my point of view this is not very convincing but you're the Python
> Czar consequently bowing to it.

OK, here's a concrete example:

$ python2.6 -c "range(5.0)"
-c:1: DeprecationWarning: integer argument expected, got float
$ echo $?
0
$ python2.7 -c "range(5.0)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: range() integer end argument expected, got float.
$ echo $?
1

I'm not denying that the backwards compatibility is high, I'm saying
that if you run Python in production, you must test before switching
and you must have the options of rolling back.

>> In short, you cannot make our users run 2.7 on our call. They need to
>> switch to 2.7 at their own schedule, and we need to make it very clear
>> about when we're pulling the plug on 2.6.
>
> The moment of switch will be when this unstable becomes a named version,
> i.e. stable. However, nothing precludes to still have legacy 2.6 modules
> in it.

The CSWpy- prefix does preclude 2.6 from having legacy packages,
unless we do something specific.

Before:
CSWpy-foo contains /opt/csw/lib/python/site-packages/foo.py

Rebuilding CSWpy-foo with Python 2.7, and:

After:
CSWpy-foo contains /opt/csw/lib/python2.7/site-packages/foo.py

And now the module doesn't work with 2.6 any more. This is the main
blocker for using the CSWpy- prefix for 2.7 modules.

Back to pyshared. I've read the policy, but it doesn't provide any
details. The pyshared functionality might be lurking in their
packaging helper tools, dh_python2 and dh_python3. We need to look
into how it's done. Until then, we can continue building modules with
Python 2.6: they will work with Python 2.6 and 2.7.

Maciej