| 1 |
On Sat, 29 Sep 2012 21:20:00 +0200 |
| 2 |
Pacho Ramos <pacho@g.o> wrote: |
| 3 |
|
| 4 |
> El sáb, 29-09-2012 a las 20:40 +0200, Michał Górny escribió: |
| 5 |
> > On Sat, 29 Sep 2012 17:45:07 +0200 |
| 6 |
> > hasufell <hasufell@g.o> wrote: |
| 7 |
> > |
| 8 |
> > > -----BEGIN PGP SIGNED MESSAGE----- |
| 9 |
> > > Hash: SHA1 |
| 10 |
> > > |
| 11 |
> > > On 09/29/2012 05:37 PM, Ian Stakenvicius wrote: |
| 12 |
> > > > |
| 13 |
> > > > There isn't so much a problem with the current python-distutils-ng |
| 14 |
> > > > eclass but rather it's to expand it to a more comprehensive |
| 15 |
> > > > replacement for both distutils and python eclasses. In order to |
| 16 |
> > > > do that efficiently, most of the core functionality should be moved |
| 17 |
> > > > so that the new distutils is more like a wrapper to the new |
| 18 |
> > > > python. |
| 19 |
> > > > |
| 20 |
> > > > This could certainly be done by patching the existing eclass, but |
| 21 |
> > > > mgorny wants to use new eclass names instead of keeping the |
| 22 |
> > > > current one. Hence the rename. I think that's about it.. |
| 23 |
> > > > |
| 24 |
> > > |
| 25 |
> > > In that case we are missing 95% of the features of python.eclass. |
| 26 |
> > |
| 27 |
> > Please list the features. Preferably, order them by usefulness, with |
| 28 |
> > exact use cases. |
| 29 |
> > |
| 30 |
> |
| 31 |
> Personally, I usually run: |
| 32 |
> - python_clean_py-compile_files -> Clean py-compile files to disable |
| 33 |
> byte-compilation allowing us to drop all various ways of doing this that |
| 34 |
> were living in the tree some time ago. |
| 35 |
|
| 36 |
Hmm, what's the problem with compiling them? Do you mean some case when |
| 37 |
the results of the compilation are different from the way done |
| 38 |
by the eclass? |
| 39 |
|
| 40 |
> - python_convert_shebangs -> but, I guess this is handled in a different |
| 41 |
> way in your eclass, no? :/ |
| 42 |
|
| 43 |
Depends on what you need. To be honest, I haven't added any code for |
| 44 |
custom script handling yet, just the usual distutils case. |
| 45 |
|
| 46 |
A package which does not explicitly support multiple Python |
| 47 |
implementations is a completely different things, needing more |
| 48 |
discussion first and which actually may be handled through a separate |
| 49 |
eclass if most code of python-r1 proves useless for it. |
| 50 |
|
| 51 |
-- |
| 52 |
Best regards, |
| 53 |
Michał Górny |
Archives