On Sat, Jul 20, 2013 at 8:28 AM, Peter FELECAN <[email protected]> wrote: > "Maciej (Matchek) Bliziński" <[email protected]> writes: > >> 2013/7/19 Peter FELECAN <[email protected]> >>> (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... > >> 2013/7/19 Peter FELECAN <[email protected]> > >>> 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. Thanks -Ben _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
