* [gentoo-python] To refactor python-distutils-ng or introduce distutils-r1?
@ 2012-09-26 13:16 Michał Górny
2012-09-30 5:16 ` Ben de Groot
0 siblings, 1 reply; 3+ messages in thread
From: Michał Górny @ 2012-09-26 13:16 UTC (permalink / raw
To: gentoo-python
[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]
Hello,
I'd like to bring a quick topic, preferably answered yes/no, preferably
after reading the remaining part ;).
Considering that python-r1 patches so far are clean, should I:
a) integrate python-distutils-ng with python-r1 and change its API
as listed below (the API changes don't collide with any used
functionality),
b) leave python-distutils-ng in place and work on distutils-r1 with
a clean start.
And now what changes in API will be necessary to make p-d-ng play nice
with python-r1. I've assumed that functions prefixed with an underscore
are private and didn't care about them.
None of the listed features are used by any ebuild in the tree, unless
I have missed something ;).
1. Remove PYTHON_OPTIONAL -- I really dislike the way it is done
(it's practically a switch to hardwire 'python?' in a few places,
without any flexibility);
2. Convert PYTHON_COMPAT to an array -- this will usually mean that
ebuilds can't look up ${PYTHON_COMPAT} safely (the change is done
for practical reasons);
3. Stop passing Python ABI and executable as parameters to phase
functions -- these are not really useful (since they are available
as ${EPYTHON} and ${PYTHON} anyway. Removing them will allow me to
implement a 'foreach' function being able to pass arbitrary
parameters to invoked commands.
What do you think? Should I change p-d-ng ABI like that (errr, how I
hate that name) or just introduce a new eclass?
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [gentoo-python] To refactor python-distutils-ng or introduce distutils-r1?
2012-09-26 13:16 [gentoo-python] To refactor python-distutils-ng or introduce distutils-r1? Michał Górny
@ 2012-09-30 5:16 ` Ben de Groot
2012-09-30 6:06 ` Michał Górny
0 siblings, 1 reply; 3+ messages in thread
From: Ben de Groot @ 2012-09-30 5:16 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-python
On 26 September 2012 21:16, Michał Górny <mgorny@gentoo.org> wrote:
> Hello,
>
> I'd like to bring a quick topic, preferably answered yes/no, preferably
> after reading the remaining part ;).
>
> Considering that python-r1 patches so far are clean, should I:
>
> a) integrate python-distutils-ng with python-r1 and change its API
> as listed below (the API changes don't collide with any used
> functionality),
>
> b) leave python-distutils-ng in place and work on distutils-r1 with
> a clean start.
>
>
> And now what changes in API will be necessary to make p-d-ng play nice
> with python-r1. I've assumed that functions prefixed with an underscore
> are private and didn't care about them.
>
> None of the listed features are used by any ebuild in the tree, unless
> I have missed something ;).
>
> 1. Remove PYTHON_OPTIONAL -- I really dislike the way it is done
> (it's practically a switch to hardwire 'python?' in a few places,
> without any flexibility);
>
> 2. Convert PYTHON_COMPAT to an array -- this will usually mean that
> ebuilds can't look up ${PYTHON_COMPAT} safely (the change is done
> for practical reasons);
>
> 3. Stop passing Python ABI and executable as parameters to phase
> functions -- these are not really useful (since they are available
> as ${EPYTHON} and ${PYTHON} anyway. Removing them will allow me to
> implement a 'foreach' function being able to pass arbitrary
> parameters to invoked commands.
>
> What do you think? Should I change p-d-ng ABI like that (errr, how I
> hate that name) or just introduce a new eclass?
>
> --
> Best regards,
> Michał Górny
Sorry for the (relatively) late reply. I was very busy this week.
IIRC I mentioned before that I prefer new eclasses over changing the
existing ones (in absence of a real eclass versioning system).
Actually a good point was raised on -dev ML about using multiple
smaller eclasses, instead of one over-complicated one that tries to do
too much.
I 100% support going for python-r1 and distutils-r1, deprecating the
existing eclasses in use now. We may need to add one or two more new
eclasses, to replace functionality from current python.eclass.
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [gentoo-python] To refactor python-distutils-ng or introduce distutils-r1?
2012-09-30 5:16 ` Ben de Groot
@ 2012-09-30 6:06 ` Michał Górny
0 siblings, 0 replies; 3+ messages in thread
From: Michał Górny @ 2012-09-30 6:06 UTC (permalink / raw
To: Ben de Groot; +Cc: gentoo-python
[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]
On Sun, 30 Sep 2012 13:16:10 +0800
Ben de Groot <yngwin@gentoo.org> wrote:
> On 26 September 2012 21:16, Michał Górny <mgorny@gentoo.org> wrote:
> > Hello,
> >
> > I'd like to bring a quick topic, preferably answered yes/no, preferably
> > after reading the remaining part ;).
> >
> > Considering that python-r1 patches so far are clean, should I:
> >
> > a) integrate python-distutils-ng with python-r1 and change its API
> > as listed below (the API changes don't collide with any used
> > functionality),
> >
> > b) leave python-distutils-ng in place and work on distutils-r1 with
> > a clean start.
> >
> >
> > And now what changes in API will be necessary to make p-d-ng play nice
> > with python-r1. I've assumed that functions prefixed with an underscore
> > are private and didn't care about them.
> >
> > None of the listed features are used by any ebuild in the tree, unless
> > I have missed something ;).
> >
> > 1. Remove PYTHON_OPTIONAL -- I really dislike the way it is done
> > (it's practically a switch to hardwire 'python?' in a few places,
> > without any flexibility);
> >
> > 2. Convert PYTHON_COMPAT to an array -- this will usually mean that
> > ebuilds can't look up ${PYTHON_COMPAT} safely (the change is done
> > for practical reasons);
> >
> > 3. Stop passing Python ABI and executable as parameters to phase
> > functions -- these are not really useful (since they are available
> > as ${EPYTHON} and ${PYTHON} anyway. Removing them will allow me to
> > implement a 'foreach' function being able to pass arbitrary
> > parameters to invoked commands.
> >
> > What do you think? Should I change p-d-ng ABI like that (errr, how I
> > hate that name) or just introduce a new eclass?
> >
> > --
> > Best regards,
> > Michał Górny
>
> Sorry for the (relatively) late reply. I was very busy this week.
No problem, I remembered your vote from the last time we spoke :).
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-09-30 6:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-26 13:16 [gentoo-python] To refactor python-distutils-ng or introduce distutils-r1? Michał Górny
2012-09-30 5:16 ` Ben de Groot
2012-09-30 6:06 ` Michał Górny
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox