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