[csw-maintainers] Python 3.x

[Yann Rouillard]

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 <yann at pleiades.fr.eu.org>

> 2013/8/2 Maciej (Matchek) Bliziński <maciej at 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20130802/32363424/attachment.html>