[csw-maintainers] Python 2.7

Peter FELECAN pfelecan at opencsw.org
Sat Jul 20 09:59:10 CEST 2013


Ben Walton <bwalton at opencsw.org> writes:

> On Sat, Jul 20, 2013 at 8:28 AM, Peter FELECAN <pfelecan at opencsw.org> wrote:
>> "Maciej (Matchek) Bliziński" <maciej at opencsw.org> writes:
>>
>>> 2013/7/19 Peter FELECAN <pfelecan at opencsw.org>
>>>> (snip)
>>>> 3. 2.7 becomes the default python for our distribution, thus new
>>>>    packages depends on it and the gar python recipe adapts to this but
>>>>    using CSWpy- prefix; I'm hesitating to add that we can obsolete
>>>>    CSWpython-xxx by CSWpython27-xxx
>>>
>>> I can imagine the following scenario:
>>>
>>> User: I upgraded CSW stuff and my application is not working, it fails
>>> with "ImportError: No module named foo"
>>> Us: Which Python are you using?
>>> User: Python 2.6
>>> Us: We made Python 2.7 the default and we're removing Python 2.6 support.
>>> User: But my application requires Python 2.6.
>>> Us: Then update your application.
>>> User: It's a third party application, we cannot modify it.
>>
>> What about this:
>
> I'd be very tempted to release the 2.6 stack with proper library
> directories and fill in missing modules as needed. The preference
> would be to build modules for 2.7 but we could reasonably easily build
> for both...

The idea is to make the transition to 2.7. Additional work on 2.6 is a
effort expense that we cannot afford given our resources. Concentrating
on 2.7 and using the least effort path is crucial.

>>> 2013/7/19 Peter FELECAN <pfelecan at opencsw.org>
>>
>>>> I'm still hoping that someone explains me why code written for 2.6
>>>> cannot be run by a 2.7 interpreter.
>>
>> which is, I think, crucial to our discussion.
>
>
> Most of the modules would work. Binary stuff doesn't (or at least may
> not) as you've mentioned. Versioned library paths are the way to go
> though. Not fixing this now just kicks the can down the road.

If "Most" means 90% then what I proposed is a good compromise. If we can
easily identify which are the "binary" modules, we have a perfect
solution with a minimal investment.

Look at what Debian has done to make the transition. They are not using
specific 2.7 packages, the differentiation is 2 versus 3 which is
understandable as there is an incompatibility between code written for 2
running in 3.

I would like to be understood that what I'm aiming at is 2 pronged:

1. minimal investment
2. fastest turn around

-- 
Peter


More information about the maintainers mailing list