El sáb, 29-09-2012 a las 22:34 +0200, Michał Górny escribió:
> On Sat, 29 Sep 2012 21:20:00 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > El sáb, 29-09-2012 a las 20:40 +0200, Michał Górny escribió:
> > > On Sat, 29 Sep 2012 17:45:07 +0200
> > > hasufell <hasufell@gentoo.org> wrote:
> > > 
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > > 
> > > > On 09/29/2012 05:37 PM, Ian Stakenvicius wrote:
> > > > > 
> > > > > There isn't so much a problem with the current python-distutils-ng 
> > > > > eclass but rather it's to expand it to a more comprehensive 
> > > > > replacement for both distutils and python eclasses.  In order to
> > > > > do that efficiently, most of the core functionality should be moved
> > > > > so that the new distutils is more like a wrapper to the new
> > > > > python.
> > > > > 
> > > > > This could certainly be done by patching the existing eclass, but 
> > > > > mgorny wants to use new eclass names instead of keeping the
> > > > > current one.  Hence the rename.  I think that's about it..
> > > > > 
> > > > 
> > > > In that case we are missing 95% of the features of python.eclass.
> > > 
> > > Please list the features. Preferably, order them by usefulness, with
> > > exact use cases.
> > > 
> > 
> > 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 :( )

> > - python_convert_shebangs -> but, I guess this is handled in a different
> > way in your eclass, no? :/
> 
> Depends on what you need. To be honest, I haven't added any code for
> custom script handling yet, just the usual distutils case.
> 
> A package which does not explicitly support multiple Python
> implementations is a completely different things, needing more
> discussion first and which actually may be handled through a separate
> eclass if most code of python-r1 proves useless for it.
> 

I was thinking on a lot of packages still being only compatible with
python2... I guess will need to still use python.eclass for them then