Ben Walton <[email protected]> writes: > 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...
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 <[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. 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 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
