Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass

[Brian Harring]

On Sun, Sep 30, 2012 at 10:58:06AM +0200, Fabian Groffen wrote:
> On 30-09-2012 10:31:17 +0200, Pacho Ramos wrote:
> > > > Personally, I usually run:
> > > > - python_clean_py-compile_files -> Clean py-compile files to disable
> > > > byte-compilation allowing us to drop all various ways of doing this that
> > > > were living in the tree some time ago.
> > >
> > > Hmm, what's the problem with compiling them? Do you mean some case when
> > > the results of the compilation are different from the way done
> > > by the eclass?
> > >
> >
> > Well, if I don't misremember, we currently prefer to compile them at
> > postinst phase instead of during src_compile, but maybe this is no
> > longer needed (no idea :( )
>
> The files are indeed cache, and should be generated on the system that
> installs the files, not the system that builds them.  They are currently
> outside of VDB.  pyc files store the path to the original files, so
> generating in ${ROOT} yields in wrong paths.  Python sometimes
> regenerates the files when it runs.  It may as well just ignore them
> (since they are newer but non-matching, unclear to me).

.pyc should be compatible within slotted python versions; 
recompilation occurs if .pyc/.pyo mtime differs from the originating 
.py.  Via EAPI=3 mtime gurantees, that should be addressed- below 
that, compilation via pkg_postinst is necessary due to the lack of 
mtime guarantees.

> In the worst case it returns "Bad marshalling data".

Examples wanted for this.  If this occurs, that's a python bug- one 
exception... portage (figures).  They install into a non 
/usr/lib/python* location, meaning the .pyc/.pyo from py2.6 is 
exposed/accessed for py2.7 for example.

That said, a .pyc/.pyo from an older python version causing a blow up 
in a differing python version hasn't occurred since the 2.3 -> 2.4 
transition (if memory serves).

Either way, examples desired please.
~harring