[gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Maxim Koltsov]

Hi,
This can be another troll-thread or layman-thread, but still I think
this question must be raised once more.
I want to say that I personally don't want to use python-distutils-ng
in its current state and I know several active python ebuild writers
that are not Gentoo developers and they don't want to use it too.
First of all, how well is this eclass adapted to packages not using
distutils? Old eclass had set of convenient functions
(python_execute_function, python_generate_wrapper_scripts,
python_conver_shebangs). I see some functions like these ones in new
eclass, but can they serve as good replace and is their API public and
stable?
Then, we think that this ruby-ng style approach with PYTHON_TARGETS is
a bit uncomfortable for end users and developers. This is going to be
pain for all users if eclass gets used widely. Eclass allows developer
not to set PYTHON_COMPAT and populate it with all available values —
well, it's nice. But imagine that Python 3.3 arrives. All ebuilds
using new eclass will get new IUSE and therefore will be rebuilt
during emerge --update --newuse world. That's hardly sensible. It's
awful to rebuild packages which might be very 'heavy' just for
nothing.
On the other hand, if developers are forced to set PYTHON_COMPAT, this
will result in great delays in getting new python support to Gentoo.
You can say that ruby-ng has the same behavior and nobody complains.
But python is not ruby. Ruby 1.8 to 1.9 transitition was connected
with a lot of incompabilities, so one could not assume that ruby-1.8
package will work on 1.9. Python 3.2 to 3.3 transitition should be
harmless and almost all packages will require no changes. So some
implicit mechanism of doing this must be implemented.
So, new eclass has serious problems, old is bad too, not to say here
why, and we have no solution yet :)
But still discussion is needed, or we will end up accepting silently
bad decisions. Please speak up everyone who agrees with me and/or has
any suggestions.

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Dirkjan Ochtman]

Hi,

On Sat, May 26, 2012 at 11:32 AM, Maxim Koltsov <maksbotan@gentoo.org> wrote:
> First of all, how well is this eclass adapted to packages not using
> distutils? Old eclass had set of convenient functions
> (python_execute_function, python_generate_wrapper_scripts,
> python_conver_shebangs). I see some functions like these ones in new
> eclass, but can they serve as good replace and is their API public and
> stable?

We will have to make sure there is good support for non-distutils
packages, it will just take some time and good bug reports about what
you need from the eclass. If you're asking if these new functions are
a good replacement, are public and stable, it seems you haven't yet
decided they're not. I don't think we (as in the python team) are
promoting python-distutils-ng as the default eclass *at this time*, so
it might take some time to work things out, but hopefully we can find
good solutions to all the issues you mention here.

> Then, we think that this ruby-ng style approach with PYTHON_TARGETS is
> a bit uncomfortable for end users and developers. This is going to be
> pain for all users if eclass gets used widely. Eclass allows developer
> not to set PYTHON_COMPAT and populate it with all available values —
> well, it's nice. But imagine that Python 3.3 arrives. All ebuilds
> using new eclass will get new IUSE and therefore will be rebuilt
> during emerge --update --newuse world. That's hardly sensible. It's
> awful to rebuild packages which might be very 'heavy' just for
> nothing.
> On the other hand, if developers are forced to set PYTHON_COMPAT, this
> will result in great delays in getting new python support to Gentoo.
> You can say that ruby-ng has the same behavior and nobody complains.
> But python is not ruby. Ruby 1.8 to 1.9 transitition was connected
> with a lot of incompabilities, so one could not assume that ruby-1.8
> package will work on 1.9. Python 3.2 to 3.3 transitition should be
> harmless and almost all packages will require no changes. So some
> implicit mechanism of doing this must be implemented.

So I think the second part of this (x.y to x.y+1 transitions, in the
Python world, are generally relatively smooth) invalidates your point
in the first part: if the transitions are generally smooth, then yes,
when Python 3.3 gets stabilized, I want all of my Python packages to
be available from the 3.3 interpreter. I agree that it's annoying to
have to rebuild all those packages, but on the other hand, rebuilding
the Python parts of my system every 18 months or so doesn't seem that
big of an issue compared to the upside. And the parts that you least
want to rebuild (e.g. big binary Python modules) are probably the ones
that it would be hardest to think of some alternate solution for, so
let's not even go there.

> So, new eclass has serious problems, old is bad too, not to say here
> why, and we have no solution yet :)
> But still discussion is needed, or we will end up accepting silently
> bad decisions. Please speak up everyone who agrees with me and/or has
> any suggestions.

> I want to say that I personally don't want to use python-distutils-ng
> in its current state and I know several active python ebuild writers
> that are not Gentoo developers and they don't want to use it too.

Given all of the above, these two paragraphs seem a little bit vague
and alarmist to me. Yes, the new eclass isn't perfect. We don't expect
it to be, certainly not given the short time it's been in the tree.
But I don't think your implicit suggestion that the python team or
anyone involved is "silently accepting bad decisions" is warranted.
Obviously no one should be shy about raising actual issues he/she has
with the ebuild or suggesting improvements (and as far as I've seen,
people haven't been, but maybe I'm not talking to the same people you
are).

So, I'd prefer it if, instead of speaking up about general concerns
that the new eclass isn't ready or has serious problems, people please
file one bug each about each serious problem they have run into,
found, or are concerned about, CC the python team, and we'll try to
take a look.

Cheers,

Dirkjan

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Nikolaj Sjujskij]

> So I think the second part of this (x.y to x.y+1 transitions, in the
> Python world, are generally relatively smooth) invalidates your point
> in the first part: if the transitions are generally smooth, then yes,
> when Python 3.3 gets stabilized, I want all of my Python packages to
> be available from the 3.3 interpreter.
  Let's take a "stable" user who updates (`emerge --update --deep --newuse  
@world`) his/her system regularly.
Python 3.3 is released, added to Portage tree and eventually unmasked.
PYTHON_TARGETS variable is changed to include 3.3. And suddenly `emerge  
--newuse @world` on stable system suggests rebuilding of every package  
using new eclass, because new (though disabled) USE-flags was added. And  
when Python 3.3 is keyworded stable, hence bringing new default  
PYTHON_TARGETS, user should now rebuild those packages once more, but now,  
at least, not uselessly.

Just yesterday I had www-servers/uwsgi recompiled because of changed  
RUBY_TARGETS. And I even have no Ruby installed.

> So, I'd prefer it if, instead of speaking up about general concerns
> that the new eclass isn't ready or has serious problems, people please
> file one bug each about each serious problem they have run into,
> found, or are concerned about, CC the python team, and we'll try to
> take a look.
  I had written about problems with new eclass a couple of weeks ago here.  
Not that anybody cares that now any user not caring about dev-lang/python  
explicitly would get Python 2.7 and all his modules compiled twice for no  
good reason (except "we can't think out more sensible default for new  
eclass"). Whether or not does he *really* need Python 2.x or stable and  
included-in-stage3 Python 3.2 suffices for him.

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

On Sat, 26 May 2012 17:01:26 +0400
"Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:

> > So I think the second part of this (x.y to x.y+1 transitions, in the
> > Python world, are generally relatively smooth) invalidates your
> > point in the first part: if the transitions are generally smooth,
> > then yes, when Python 3.3 gets stabilized, I want all of my Python
> > packages to be available from the 3.3 interpreter.
>   Let's take a "stable" user who updates (`emerge --update --deep
> --newuse @world`) his/her system regularly.
> Python 3.3 is released, added to Portage tree and eventually unmasked.
> PYTHON_TARGETS variable is changed to include 3.3. And suddenly
> `emerge --newuse @world` on stable system suggests rebuilding of
> every package using new eclass, because new (though disabled)
> USE-flags was added. And when Python 3.3 is keyworded stable, hence
> bringing new default PYTHON_TARGETS, user should now rebuild those
> packages once more, but now, at least, not uselessly.
> 
> Just yesterday I had www-servers/uwsgi recompiled because of changed  
> RUBY_TARGETS. And I even have no Ruby installed.

I suggest you report a bug against portage and/or PMS.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Nikolaj Sjujskij]

Den 2012-05-26 17:07:29 skrev Michał Górny <mgorny@gentoo.org>:

> On Sat, 26 May 2012 17:01:26 +0400
> "Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:
>
>> > So I think the second part of this (x.y to x.y+1 transitions, in the
>> > Python world, are generally relatively smooth) invalidates your
>> > point in the first part: if the transitions are generally smooth,
>> > then yes, when Python 3.3 gets stabilized, I want all of my Python
>> > packages to be available from the 3.3 interpreter.
>>   Let's take a "stable" user who updates (`emerge --update --deep
>> --newuse @world`) his/her system regularly.
>> Python 3.3 is released, added to Portage tree and eventually unmasked.
>> PYTHON_TARGETS variable is changed to include 3.3. And suddenly
>> `emerge --newuse @world` on stable system suggests rebuilding of
>> every package using new eclass, because new (though disabled)
>> USE-flags was added. And when Python 3.3 is keyworded stable, hence
>> bringing new default PYTHON_TARGETS, user should now rebuild those
>> packages once more, but now, at least, not uselessly.
>>
>> Just yesterday I had www-servers/uwsgi recompiled because of changed
>> RUBY_TARGETS. And I even have no Ruby installed.
>
> I suggest you report a bug against portage and/or PMS.
  Excuse me, but I really fail to see how this could be their fault.

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Krzysztof Pawlik]

[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]

On 26/05/12 15:09, Nikolaj Sjujskij wrote:
> Den 2012-05-26 17:07:29 skrev Michał Górny <mgorny@gentoo.org>:
> 
>> On Sat, 26 May 2012 17:01:26 +0400
>> "Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:
>>
>>> > So I think the second part of this (x.y to x.y+1 transitions, in the
>>> > Python world, are generally relatively smooth) invalidates your
>>> > point in the first part: if the transitions are generally smooth,
>>> > then yes, when Python 3.3 gets stabilized, I want all of my Python
>>> > packages to be available from the 3.3 interpreter.
>>>   Let's take a "stable" user who updates (`emerge --update --deep
>>> --newuse @world`) his/her system regularly.
>>> Python 3.3 is released, added to Portage tree and eventually unmasked.
>>> PYTHON_TARGETS variable is changed to include 3.3. And suddenly
>>> `emerge --newuse @world` on stable system suggests rebuilding of
>>> every package using new eclass, because new (though disabled)
>>> USE-flags was added. And when Python 3.3 is keyworded stable, hence
>>> bringing new default PYTHON_TARGETS, user should now rebuild those
>>> packages once more, but now, at least, not uselessly.
>>>
>>> Just yesterday I had www-servers/uwsgi recompiled because of changed
>>> RUBY_TARGETS. And I even have no Ruby installed.
>>
>> I suggest you report a bug against portage and/or PMS.
>  Excuse me, but I really fail to see how this could be their fault.

Yes, you do. Let me explain: there was a thread some time ago about portage
rebuilding package when new USE flag is introduced in ebuild that does not
change enabled USE set, that's how it's related.

-- 
Krzysztof Pawlik  <nelchael at gentoo.org>  key id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 554 bytes --]

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Maxim Koltsov]

2012/5/26 Krzysztof Pawlik <nelchael@gentoo.org>:
> On 26/05/12 15:09, Nikolaj Sjujskij wrote:
>> Den 2012-05-26 17:07:29 skrev Michał Górny <mgorny@gentoo.org>:
>>
>>> On Sat, 26 May 2012 17:01:26 +0400
>>> "Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:
>>>
>>>> > So I think the second part of this (x.y to x.y+1 transitions, in the
>>>> > Python world, are generally relatively smooth) invalidates your
>>>> > point in the first part: if the transitions are generally smooth,
>>>> > then yes, when Python 3.3 gets stabilized, I want all of my Python
>>>> > packages to be available from the 3.3 interpreter.
>>>>   Let's take a "stable" user who updates (`emerge --update --deep
>>>> --newuse @world`) his/her system regularly.
>>>> Python 3.3 is released, added to Portage tree and eventually unmasked.
>>>> PYTHON_TARGETS variable is changed to include 3.3. And suddenly
>>>> `emerge --newuse @world` on stable system suggests rebuilding of
>>>> every package using new eclass, because new (though disabled)
>>>> USE-flags was added. And when Python 3.3 is keyworded stable, hence
>>>> bringing new default PYTHON_TARGETS, user should now rebuild those
>>>> packages once more, but now, at least, not uselessly.
>>>>
>>>> Just yesterday I had www-servers/uwsgi recompiled because of changed
>>>> RUBY_TARGETS. And I even have no Ruby installed.
>>>
>>> I suggest you report a bug against portage and/or PMS.
>>  Excuse me, but I really fail to see how this could be their fault.
>
> Yes, you do. Let me explain: there was a thread some time ago about portage
> rebuilding package when new USE flag is introduced in ebuild that does not
> change enabled USE set, that's how it's related.

This was my first thought too: if just appeared flag is not set, there
is no sense to rebuild. But there is one possible case when this
assumption is false. Image that foo has support for bar and this
support was on by default and had no useflag. Suddenly package
maintainer decides, no matter why, make it optional and off by
default. He adds useflag to IUSE and it's not set by default. Then not
rebuilding it is *wrong* behavior.
Yes i know that this example is rather abstract and very unlikely to
happen, but we must consider all cases.

> --
> Krzysztof Pawlik  <nelchael at gentoo.org>  key id: 0xF6A80E46
> desktop-misc, java, vim, kernel, python, apache...
>

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]

On Sat, 26 May 2012 22:45:18 +0400
Maxim Koltsov <maksbotan@gentoo.org> wrote:

> 2012/5/26 Krzysztof Pawlik <nelchael@gentoo.org>:
> > On 26/05/12 15:09, Nikolaj Sjujskij wrote:
> >> Den 2012-05-26 17:07:29 skrev Michał Górny <mgorny@gentoo.org>:
> >>
> >>> On Sat, 26 May 2012 17:01:26 +0400
> >>> "Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:
> >>>
> >>>> > So I think the second part of this (x.y to x.y+1 transitions,
> >>>> > in the Python world, are generally relatively smooth)
> >>>> > invalidates your point in the first part: if the transitions
> >>>> > are generally smooth, then yes, when Python 3.3 gets
> >>>> > stabilized, I want all of my Python packages to be available
> >>>> > from the 3.3 interpreter.
> >>>>   Let's take a "stable" user who updates (`emerge --update --deep
> >>>> --newuse @world`) his/her system regularly.
> >>>> Python 3.3 is released, added to Portage tree and eventually
> >>>> unmasked. PYTHON_TARGETS variable is changed to include 3.3. And
> >>>> suddenly `emerge --newuse @world` on stable system suggests
> >>>> rebuilding of every package using new eclass, because new
> >>>> (though disabled) USE-flags was added. And when Python 3.3 is
> >>>> keyworded stable, hence bringing new default PYTHON_TARGETS,
> >>>> user should now rebuild those packages once more, but now, at
> >>>> least, not uselessly.
> >>>>
> >>>> Just yesterday I had www-servers/uwsgi recompiled because of
> >>>> changed RUBY_TARGETS. And I even have no Ruby installed.
> >>>
> >>> I suggest you report a bug against portage and/or PMS.
> >>  Excuse me, but I really fail to see how this could be their fault.
> >
> > Yes, you do. Let me explain: there was a thread some time ago about
> > portage rebuilding package when new USE flag is introduced in
> > ebuild that does not change enabled USE set, that's how it's
> > related.
> 
> This was my first thought too: if just appeared flag is not set, there
> is no sense to rebuild. But there is one possible case when this
> assumption is false. Image that foo has support for bar and this
> support was on by default and had no useflag. Suddenly package
> maintainer decides, no matter why, make it optional and off by
> default. He adds useflag to IUSE and it's not set by default. Then not
> rebuilding it is *wrong* behavior.
> Yes i know that this example is rather abstract and very unlikely to
> happen, but we must consider all cases.

Then author may revbump the package to make users happier.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Nikolaj Sjujskij]

Den 2012-05-26 22:28:11 skrev Krzysztof Pawlik <nelchael@gentoo.org>:

>>>> Just yesterday I had www-servers/uwsgi recompiled because of changed
>>>> RUBY_TARGETS. And I even have no Ruby installed.
>>>
>>> I suggest you report a bug against portage and/or PMS.
>>  Excuse me, but I really fail to see how this could be their fault.
>
> Yes, you do. Let me explain: there was a thread some time ago about  
> portage rebuilding package when new USE flag is introduced in ebuild
> that does not change enabled USE set, that's how it's related.
  All right, I get your point. But I wouldn't consider it a bug, rather a  
not-so-good implementation.
In any case, it's what we have to deal for now and while Portage behaves  
this way.

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Mike Gilbert]

On Sat, May 26, 2012 at 9:01 AM, Nikolaj Sjujskij <sterkrig@myopera.com> wrote:
>> So I think the second part of this (x.y to x.y+1 transitions, in the
>> Python world, are generally relatively smooth) invalidates your point
>> in the first part: if the transitions are generally smooth, then yes,
>> when Python 3.3 gets stabilized, I want all of my Python packages to
>> be available from the 3.3 interpreter.
>
>  Let's take a "stable" user who updates (`emerge --update --deep --newuse
> @world`) his/her system regularly.
> Python 3.3 is released, added to Portage tree and eventually unmasked.
> PYTHON_TARGETS variable is changed to include 3.3. And suddenly `emerge
> --newuse @world` on stable system suggests rebuilding of every package using
> new eclass, because new (though disabled) USE-flags was added. And when
> Python 3.3 is keyworded stable, hence bringing new default PYTHON_TARGETS,
> user should now rebuild those packages once more, but now, at least, not
> uselessly.
>

This is why I do my world updates with --changed-use instead of
--newuse. The package manager already has the ability to deal with
such scenarios intelligently, you just have to let it.

>  I had written about problems with new eclass a couple of weeks ago here.
> Not that anybody cares that now any user not caring about dev-lang/python
> explicitly would get Python 2.7 and all his modules compiled twice for no
> good reason (except "we can't think out more sensible default for new
> eclass"). Whether or not does he *really* need Python 2.x or stable and
> included-in-stage3 Python 3.2 suffices for him.
>

I did not speak up in the previous thread, but here are some of the
advantages to a use flag based approach (PYTHON_TARGETS):

- Ability to express proper dependencies on dev-lang/python and
between python packages.
- Makes python-updater obsolete (I think).
- Better support for binpkgs.

The disadvantage is that you must maintain another variable in
make.conf, or accept the default value that is assigned in the
profile.

Here is how I justify the current default value of PYTHON_TARGETS: Due
to past decisions, python3.2 is installed by default on all amd64 and
x86 systems, so having python3_2 enabled by default makes sense.
However, there are many things do not work in python 3, so the
python2_7 target is a necessity.

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Nikolaj Sjujskij]

Den 2012-05-26 17:33:45 skrev Mike Gilbert <floppym@gentoo.org>:

>>  Let's take a "stable" user who updates (`emerge --update --deep  
>> --newuse
>> @world`) his/her system regularly.
>> Python 3.3 is released, added to Portage tree and eventually unmasked.
>> PYTHON_TARGETS variable is changed to include 3.3. And suddenly `emerge
>> --newuse @world` on stable system suggests rebuilding of every package  
>> using
>> new eclass, because new (though disabled) USE-flags was added. And when
>> Python 3.3 is keyworded stable, hence bringing new default  
>> PYTHON_TARGETS,
>> user should now rebuild those packages once more, but now, at least, not
>> uselessly.
> This is why I do my world updates with --changed-use instead of
> --newuse. The package manager already has the ability to deal with
> such scenarios intelligently, you just have to let it.
  Point taken, but --newuse is still "recommended" option (i.e.,  
`--depclean` suggests it and Handbook describes it as well). Whereas  
'--changed-use' is more or less "spoken lore" among users.

> I did not speak up in the previous thread, but here are some of the
> advantages to a use flag based approach (PYTHON_TARGETS):
> ...
  Agreed.

> Here is how I justify the current default value of PYTHON_TARGETS: Due
> to past decisions, python3.2 is installed by default on all amd64 and
> x86 systems, so having python3_2 enabled by default makes sense.
> However, there are many things do not work in python 3, so the
> python2_7 target is a necessity.
  Yes, I understand that. It is really the most sensible default in the  
circumstances.
Still, it is a bit clumsy with new installs. It'd be nice if stage3 had  
PYTHON_TARGETS="python32" (since it's the only Python interpreter  
installed), while profile had current default.
Of course, news item is a must for that kind of thing. Describing new  
variable, suggesting `--changed-use` instead of `--newuse` etc.

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]

On Sat, 26 May 2012 13:32:30 +0400
Maxim Koltsov <maksbotan@gentoo.org> wrote:

> I want to say that I personally don't want to use python-distutils-ng
> in its current state and I know several active python ebuild writers
> that are not Gentoo developers and they don't want to use it too.
> First of all, how well is this eclass adapted to packages not using
> distutils? Old eclass had set of convenient functions
> (python_execute_function, python_generate_wrapper_scripts,
> python_conver_shebangs). I see some functions like these ones in new
> eclass, but can they serve as good replace and is their API public and
> stable?

We're planning on splitting some basic 'python' eclass out of it. Just
someone needs to do that, or I'll when I'll have more time and a good
plan.

> Then, we think that this ruby-ng style approach with PYTHON_TARGETS is
> a bit uncomfortable for end users and developers. This is going to be
> pain for all users if eclass gets used widely. Eclass allows developer
> not to set PYTHON_COMPAT and populate it with all available values —
> well, it's nice.

I think we can disable that early if new Python versions are likely to
introduce breakages.

> But imagine that Python 3.3 arrives. All ebuilds
> using new eclass will get new IUSE and therefore will be rebuilt
> during emerge --update --newuse world. That's hardly sensible. It's
> awful to rebuild packages which might be very 'heavy' just for
> nothing.

We don't support '--newuse' in Gentoo. People who do that are on their
own. We have enough problems to care about in our workflow.

> On the other hand, if developers are forced to set PYTHON_COMPAT, this
> will result in great delays in getting new python support to Gentoo.
> You can say that ruby-ng has the same behavior and nobody complains.
> But python is not ruby. Ruby 1.8 to 1.9 transitition was connected
> with a lot of incompabilities, so one could not assume that ruby-1.8
> package will work on 1.9. Python 3.2 to 3.3 transitition should be
> harmless and almost all packages will require no changes. So some
> implicit mechanism of doing this must be implemented.

I guess that 3.2->3.3 would include having python3_3 masked for
a longer while to test it.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Dirkjan Ochtman]

On Sat, May 26, 2012 at 11:53 AM, Michał Górny <mgorny@gentoo.org> wrote:
> We're planning on splitting some basic 'python' eclass out of it. Just
> someone needs to do that, or I'll when I'll have more time and a good
> plan.

Who's we?

> We don't support '--newuse' in Gentoo. People who do that are on their
> own. We have enough problems to care about in our workflow.

Again, who's we?

Cheers,

Dirkjan

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

On Sat, 26 May 2012 11:55:54 +0200
Dirkjan Ochtman <djc@gentoo.org> wrote:

> On Sat, May 26, 2012 at 11:53 AM, Michał Górny <mgorny@gentoo.org>
> wrote:
> > We're planning on splitting some basic 'python' eclass out of it.
> > Just someone needs to do that, or I'll when I'll have more time and
> > a good plan.
> 
> Who's we?

People who talked about it on #gentoo-python a while ago.

> 
> > We don't support '--newuse' in Gentoo. People who do that are on
> > their own. We have enough problems to care about in our workflow.
> 
> Again, who's we?

Gentoo devs. Mostly base-system ones who add IUSE=static-libs
on a daily basis.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Krzysztof Pawlik]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

On 26/05/12 12:06, Michał Górny wrote:
> On Sat, 26 May 2012 11:55:54 +0200
> Dirkjan Ochtman <djc@gentoo.org> wrote:
> 
>> On Sat, May 26, 2012 at 11:53 AM, Michał Górny <mgorny@gentoo.org>
>> wrote:
>>> We're planning on splitting some basic 'python' eclass out of it.
>>> Just someone needs to do that, or I'll when I'll have more time and
>>> a good plan.
>>
>> Who's we?
> 
> People who talked about it on #gentoo-python a while ago.

For future: if such "decision" is being made care to let rest of the team know?
Some people have jobs, families and don't have time to hang out on IRC whole day.

>>
>>> We don't support '--newuse' in Gentoo. People who do that are on
>>> their own. We have enough problems to care about in our workflow.
>>
>> Again, who's we?
> 
> Gentoo devs. Mostly base-system ones who add IUSE=static-libs
> on a daily basis.

-- 
Krzysztof Pawlik  <nelchael at gentoo.org>  key id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 554 bytes --]

Re: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass

[Mike Gilbert]

On Sat, May 26, 2012 at 2:31 PM, Krzysztof Pawlik <nelchael@gentoo.org> wrote:
> On 26/05/12 12:06, Michał Górny wrote:
>> On Sat, 26 May 2012 11:55:54 +0200
>> Dirkjan Ochtman <djc@gentoo.org> wrote:
>>
>>> On Sat, May 26, 2012 at 11:53 AM, Michał Górny <mgorny@gentoo.org>
>>> wrote:
>>>> We're planning on splitting some basic 'python' eclass out of it.
>>>> Just someone needs to do that, or I'll when I'll have more time and
>>>> a good plan.
>>>
>>> Who's we?
>>
>> People who talked about it on #gentoo-python a while ago.
>
> For future: if such "decision" is being made care to let rest of the team know?
> Some people have jobs, families and don't have time to hang out on IRC whole day.
>

In IRC, I mentioned that we needed a generic python utility eclass
that respected PYTHON_TARGETS for ebuilds not based on distutils, and
Michał agreed. I then joked that he had just volunteered himself to
write it. That is the extent of this monumental "decision".

I don't announce every single thought I have on the mailing list.
There's no back room dealing going on here, I just happened to express
an idle thought around the water cooler.