Can you remind me why pyc compilation on post-install has be ruled out ? As I see it, there a not a ton of possibilies, either:
1. we rebuild pyc on postinstall of module packages and interpreter package, to be sure that a pyc always exists whatever the module and the interpreter, 2. we ship the pyc in the CSWpy3- packages and we rebuild every python package when we deliver a new version of the python interpreter so that it includes 3. we only care about one specific version of python which we consider our default. Every CSWpy3- package must provide a pyc for this interpreter. When we release a new python interpreter, every package can begin to include the pyc when they are rebuilt. We consider ok that a module package doesn't ship a pyc package for a non default interpreter. The day we change the default python interpreter, we have to make sure every package ships a pyc for the new default version. 4. we use CSWpy33-, CSWpy34- prefixed packages that ship the pyc files and we have to build the new set of CSWpy3X- packages each time there is a new release of the python interpreter. I think: - 3. should be avoided if possible (why ship module with slower load time if we can do otherwise), - 2 is maybe not so difficult thanks to the gar build system (but beware of package that don't build anymore because the build environment changed), - 4 maybe also not be so difficult thanks to gar but it doesn't meet the consensus of having CSWpy3- prefixed package, - 1. seems feasible without so much hassle. So 1. seems the easiest way, so why don't we go with it ? Is there some drawbacks I missed ? Yann 2013/8/2 Yann Rouillard <y...@pleiades.fr.eu.org> > 2013/8/2 Maciej (Matchek) BliziĆski <mac...@opencsw.org> > >> >> There is a mechanism, but the user has no write permissions to the >> >> directories where the modules are. >> > >> > I mean in his home directory, ${TMPDIR}, &c. >> >> I would doubt it works in a general case, e.g. you can't assume that >> there is a home directory, and I'm pretty sure Python wouldn't save >> bytecode into /tmp. >> > > That's right, a little test show that in only tries the __pycache__ > directory: > > $ truss -f python3 test.py 2>&1 | egrep "copy.*pyc" > 1395: > open64("/opt/csw/lib/python3.3/__pycache__/copyreg.cpython-33.pyc", > O_RDONLY) Err#2 ENOENT > 1395: > open64("/opt/csw/lib/python3.3/__pycache__/copyreg.cpython-33.pyc.4274440288", > O_WRONLY|O_CREAT|O_EXCL, 0644) Err#13 EACCES [ALL] > 1395: open64("/opt/csw/lib/python3.3/__pycache__/copy.cpython-33.pyc", > O_RDONLY) Err#2 ENOENT > 1395: > open64("/opt/csw/lib/python3.3/__pycache__/copy.cpython-33.pyc.4271408496", > O_WRONLY|O_CREAT|O_EXCL, 0644) Err#13 EACCES [ALL] > > and the following document which describes how __pycache__ works doesn't > talk about a user writeable directory possibility: > http://www.python.org/dev/peps/pep-3147/ > > > Yann > > > >
_______________________________________________ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.