"Maciej (Matchek) Bliziński" <[email protected]> writes: > 2013/7/29 Peter FELECAN <[email protected]>: >>> Can we prevent the above scenario in any way? For example, provide a >>> stub for 2.6 that when you try to import it, it would say: "this >>> package is for Python 2.7 only"? >> >> Meh. I don't know. It seems contrived to me. > > Contrived ‒ the problem or the solution? The problem seems pretty > straightforward to me: you install CSWpy-foo and "import foo" fails.
The solution. >>>> 2. The package provides a "mixed" module, i.e. the code runs on 2.6 and >>>> 2.7 interpreter. In this case it should provide a double pronged >>>> installation, i.e., components installed in >>>> /opt/csw/python/site-packages. >>> >>> Or instead, let's just provide files in >>> /opt/csw/python2.6/site-packages and /opt/csw/python2.7/site-packages >>> plus their compiled .pyc counterparts, compiled with respective >>> interpreters. Simple to do and effective. Why shouldn't we do this? >> >> Indeed. What I thought but not wrote... > > Cool, we have agreement on this one. It should be fairly easy to > implement with GAR modulations. I already briefly talked about this > with Dago. Good to talk with Dago about this. He can bring his salt. >>>> consequently, no need for a specific >>>> prefix and its dependency specifies CSWpython *and* CSWpython27. >>> >>> Agreed on the deps. (Also note: if we had CSWpy26- and CSWpy27-, we >>> could be more selective.) >>> >>>> 3. The package provides a 2.6 module (IMHO this is also a 2.7 >>>> module). >>> >>> It surely is, except the 2.6 .pyc files won't work for 2.7. >> >> Are you sure of that? > > Yes, see here: > > $ mkdir pyc_test > $ cd pyc_test > $ echo "print 'foo'" > foo.py > $ python2.6 -m foo > foo > $ python2.6 -m py_compile foo.py > $ ls -l foo.pyc > -rw-rw-r-- 1 maciej maciej 106 Jul 29 15:44 foo.pyc > $ mv foo.py foo_renamed.py > $ python2.6 -m foo > foo > $ python2.7 -m foo > /usr/bin/python2.7: No code object available for foo Right. But I wa writing about the case when .py exists and .pyc is from a earlier version. That works, isn't it? >> Anyway, the .pyc is rejected and .py is used which >> incurs just the extra parsing, isn't it? > > Yes. Here's the hierarchy of usefulness: > > - providing the right .pyc file > - is better than not providing a .pyc file at all > - which in turn is better than providing the wrong .pyc file > > We can accept this as a temporary state, but we should work towards > the dual 2.6+2.7 support. > >> What I propose is eventually to support 2.x and 3.x. > > I don't know if we can talk in terms of 2.x or 3.x. We aim to support > 2.6, 2.7 and 3.3. We currently do not support 2.5 (even though 2.5 is > a 2.x) nor 3.0 or 3.1 or 3.2. We'll drop the 2.6 at some point when > everything works well with 2.7. Nah. When I write "support 2.x and 3.x" I mean, support the latest version of 2 and 3. in Our case 2.7 and 3.3. > By the way, do you haven an idea how to deprecate the old 2.6 modules? > >> Can I commit the changes? > > Go ahead. I'll add the check to make sure we're not introducing > regressions for 2.6. Thanks. -- Peter _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
