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