[gentoo-python] Python 3 in Gentoo

[gentoo-python] Python 3 in Gentoo

[Mike Gilbert]

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

This past weekend, the topic of the current state of Python 3 in Gentoo
was raised once again in the #gentoo-dev IRC channel. Here's where we
currently stand:

1. Python 3.2 is installed by default on major arches due to its
presence in the stage3 tarball.

2. Python 2 is NOT installed by default as nothing in the system set
actually depends on it.

3. In most cases, users end up building and installing Python 2.7 as a
dependency of some other package once they have their system set up.
Users end up having two versions of Python installed.

This third point is the cause of some annoyance for several (many?)
developers and users. In most cases, there really is no reason for a
user to have two versions of Python installed; it is simply a redundant
set of code. However, if you attempt to remove Python 3, portage will
just pull it back on the next world upgrade unless you mask it.

I don't think this makes for a very good user experience. So, how can we
change that?

As I see it, we need a way to avoid portage's overly optimistic upgrade
mechanic. One way to do that is to drop the stable keywords on Python 3,
but I feel that is dishonest; Python 3 itself is perfectly stable, so we
should not force users to unmask it.

The other way that occurs to me (and others) is to rename
dev-lang/python-3* to dev-lang/python3, treating it as an entirely
separate package. I believe this has been proposed in the past, and I'm
honestly not sure why it never gained traction. It would take some work,
but we have already had a couple of non-python devs volunteer to help out.

We can work out the technical details in follow-up discussion.

Is anyone in favor or opposed to this package rename idea? Are there any
better ideas?


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

Re: [gentoo-python] Python 3 in Gentoo

[Richard Yao]

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

On 07/29/2012 10:13 PM, Mike Gilbert wrote:
> This past weekend, the topic of the current state of Python 3 in Gentoo
> was raised once again in the #gentoo-dev IRC channel. Here's where we
> currently stand:
> 
> 1. Python 3.2 is installed by default on major arches due to its
> presence in the stage3 tarball.
> 
> 2. Python 2 is NOT installed by default as nothing in the system set
> actually depends on it.
> 
> 3. In most cases, users end up building and installing Python 2.7 as a
> dependency of some other package once they have their system set up.
> Users end up having two versions of Python installed.
> 
> This third point is the cause of some annoyance for several (many?)
> developers and users. In most cases, there really is no reason for a
> user to have two versions of Python installed; it is simply a redundant
> set of code. However, if you attempt to remove Python 3, portage will
> just pull it back on the next world upgrade unless you mask it.
> 
> I don't think this makes for a very good user experience. So, how can we
> change that?
> 
> As I see it, we need a way to avoid portage's overly optimistic upgrade
> mechanic. One way to do that is to drop the stable keywords on Python 3,
> but I feel that is dishonest; Python 3 itself is perfectly stable, so we
> should not force users to unmask it.
> 
> The other way that occurs to me (and others) is to rename
> dev-lang/python-3* to dev-lang/python3, treating it as an entirely
> separate package. I believe this has been proposed in the past, and I'm
> honestly not sure why it never gained traction. It would take some work,
> but we have already had a couple of non-python devs volunteer to help out.
> 
> We can work out the technical details in follow-up discussion.
> 
> Is anyone in favor or opposed to this package rename idea? Are there any
> better ideas?
> 

I have already setup a github repository we could use to make the
appropriate changes to the tree at our leisure:

https://github.com/gentoo/portage-devel

Then it should be possible to do this change with minimal disruption
once we are happy with what we have there.

Also, I am willing to help. :)


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

Re: [gentoo-python] Python 3 in Gentoo

[Rafael Goncalves Martins]

Hi Mike,

On Sun, Jul 29, 2012 at 11:13 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> This past weekend, the topic of the current state of Python 3 in Gentoo
> was raised once again in the #gentoo-dev IRC channel. Here's where we
> currently stand:
>
> 1. Python 3.2 is installed by default on major arches due to its
> presence in the stage3 tarball.
>
> 2. Python 2 is NOT installed by default as nothing in the system set
> actually depends on it.
>
> 3. In most cases, users end up building and installing Python 2.7 as a
> dependency of some other package once they have their system set up.
> Users end up having two versions of Python installed.
>
> This third point is the cause of some annoyance for several (many?)
> developers and users. In most cases, there really is no reason for a
> user to have two versions of Python installed; it is simply a redundant
> set of code. However, if you attempt to remove Python 3, portage will
> just pull it back on the next world upgrade unless you mask it.
>
> I don't think this makes for a very good user experience. So, how can we
> change that?
>
> As I see it, we need a way to avoid portage's overly optimistic upgrade
> mechanic. One way to do that is to drop the stable keywords on Python 3,
> but I feel that is dishonest; Python 3 itself is perfectly stable, so we
> should not force users to unmask it.
>
> The other way that occurs to me (and others) is to rename
> dev-lang/python-3* to dev-lang/python3, treating it as an entirely
> separate package. I believe this has been proposed in the past, and I'm
> honestly not sure why it never gained traction. It would take some work,
> but we have already had a couple of non-python devs volunteer to help out.
>
> We can work out the technical details in follow-up discussion.
>
> Is anyone in favor or opposed to this package rename idea? Are there any
> better ideas?
>

I agree with any changes regarding have just python-2* installed by
default, including rename python-3* to python3.

Best Regards.

-- 
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/

Re: [gentoo-python] Python 3 in Gentoo

[Dirkjan Ochtman]

On Mon, Jul 30, 2012 at 4:13 AM, Mike Gilbert <floppym@gentoo.org> wrote:
> Is anyone in favor or opposed to this package rename idea? Are there any
> better ideas?

I've always thought renaming python-3 to python3 is faux-namespacing,
and the thing SLOTs are supposed to help out with. Why aren't SLOTs
helping us with this?

The problem I have with it is that inevitably there's going to be a
time we don't care about python-2 anymore, and we'll be stuck with the
python3 package name (or have to go through annoying mechanics to
rename it back).

I agree that installing both is probably overkill for most users. I
think the solution is somewhere outside the dev-lang/python package,
though, in having the system set or portage or whatever the hell it is
that first pulls in python prefer python-2.

Cheers,

Dirkjan

Re: [gentoo-python] Python 3 in Gentoo

[Michał Górny]

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

On Sun, 29 Jul 2012 22:13:22 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> This past weekend, the topic of the current state of Python 3 in
> Gentoo was raised once again in the #gentoo-dev IRC channel. Here's
> where we currently stand:
> 
> 1. Python 3.2 is installed by default on major arches due to its
> presence in the stage3 tarball.
> 
> 2. Python 2 is NOT installed by default as nothing in the system set
> actually depends on it.
> 
> 3. In most cases, users end up building and installing Python 2.7 as a
> dependency of some other package once they have their system set up.
> Users end up having two versions of Python installed.
> 
> This third point is the cause of some annoyance for several (many?)
> developers and users. In most cases, there really is no reason for a
> user to have two versions of Python installed; it is simply a
> redundant set of code. However, if you attempt to remove Python 3,
> portage will just pull it back on the next world upgrade unless you
> mask it.
> 
> I don't think this makes for a very good user experience. So, how can
> we change that?
> 
> As I see it, we need a way to avoid portage's overly optimistic
> upgrade mechanic. One way to do that is to drop the stable keywords
> on Python 3, but I feel that is dishonest; Python 3 itself is
> perfectly stable, so we should not force users to unmask it.

Portage is doing something like that? Paludis, yes, but portage - I
doubt it. I'm pretty sure it shouldn't pull anything in unless
something (*anything*) depends on python:3, or python without SLOT.

Well, unless you're saying that very, very smart python.eclass have
just built a lot of apps with semi-automagic dependency on python:3.*
and you didn't rebuild them all without 3.* in USE_PYTHON.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-python] Python 3 in Gentoo

[Richard Yao]

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

On 07/30/2012 03:36 AM, Dirkjan Ochtman wrote:
> On Mon, Jul 30, 2012 at 4:13 AM, Mike Gilbert <floppym@gentoo.org> wrote:
>> Is anyone in favor or opposed to this package rename idea? Are there any
>> better ideas?
> I've always thought renaming python-3 to python3 is faux-namespacing,
> and the thing SLOTs are supposed to help out with. Why aren't SLOTs
> helping us with this?

Portage will attempt to upgrade software to a newer SLOT if it will
satisfy a dependency. This works when you cannot select versions via
eselect, but it causes problems when you can. There is no way to tell it
to prefer the selected version upgrades in other slots unless the
selected version cannot satisfy it.

> The problem I have with it is that inevitably there's going to be a
> time we don't care about python-2 anymore, and we'll be stuck with the
> python3 package name (or have to go through annoying mechanics to
> rename it back).

I think that having to switch back would cause far less pain than the
current situation would, assuming that we ever do. If the python
developers refuse to make python 2.8, it is likely that someone else will.

> I agree that installing both is probably overkill for most users. I
> think the solution is somewhere outside the dev-lang/python package,
> though, in having the system set or portage or whatever the hell it is
> that first pulls in python prefer python-2.

This would require amending the package manager specification.


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

Re: [gentoo-python] Python 3 in Gentoo

[Dirkjan Ochtman]

On Mon, Jul 30, 2012 at 10:23 AM, Richard Yao <ryao@gentoo.org> wrote:
>> I've always thought renaming python-3 to python3 is faux-namespacing,
>> and the thing SLOTs are supposed to help out with. Why aren't SLOTs
>> helping us with this?
>
> Portage will attempt to upgrade software to a newer SLOT if it will
> satisfy a dependency. This works when you cannot select versions via
> eselect, but it causes problems when you can. There is no way to tell it
> to prefer the selected version upgrades in other slots unless the
> selected version cannot satisfy it.

Your last sentence fails to parse for me, perhaps expand one of the "it"s?

> I think that having to switch back would cause far less pain than the
> current situation would, assuming that we ever do. If the python
> developers refuse to make python 2.8, it is likely that someone else will.

Please don't hope for a 2.8, it's simply not going to happen.

>> I agree that installing both is probably overkill for most users. I
>> think the solution is somewhere outside the dev-lang/python package,
>> though, in having the system set or portage or whatever the hell it is
>> that first pulls in python prefer python-2.
>
> This would require amending the package manager specification.

Well, maybe we should explore that option. It would seem to solve a
real problem that doesn't just apply to python. For example, the SLOT
value could be prefixed with something to indicate that it should not
be selected for upgrades automatically (i.e. other slots should be
preferred).

Cheers,

Dirkjan

Re: [gentoo-python] Python 3 in Gentoo

[Michał Górny]

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

On Mon, 30 Jul 2012 10:32:50 +0200
Dirkjan Ochtman <djc@gentoo.org> wrote:

> On Mon, Jul 30, 2012 at 10:23 AM, Richard Yao <ryao@gentoo.org> wrote:
> >> I've always thought renaming python-3 to python3 is
> >> faux-namespacing, and the thing SLOTs are supposed to help out
> >> with. Why aren't SLOTs helping us with this?
> >
> > Portage will attempt to upgrade software to a newer SLOT if it will
> > satisfy a dependency. This works when you cannot select versions via
> > eselect, but it causes problems when you can. There is no way to
> > tell it to prefer the selected version upgrades in other slots
> > unless the selected version cannot satisfy it.
> 
> Your last sentence fails to parse for me, perhaps expand one of the
> "it"s?
> 
> > I think that having to switch back would cause far less pain than
> > the current situation would, assuming that we ever do. If the python
> > developers refuse to make python 2.8, it is likely that someone
> > else will.
> 
> Please don't hope for a 2.8, it's simply not going to happen.
> 
> >> I agree that installing both is probably overkill for most users. I
> >> think the solution is somewhere outside the dev-lang/python
> >> package, though, in having the system set or portage or whatever
> >> the hell it is that first pulls in python prefer python-2.
> >
> > This would require amending the package manager specification.
> 
> Well, maybe we should explore that option. It would seem to solve a
> real problem that doesn't just apply to python. For example, the SLOT
> value could be prefixed with something to indicate that it should not
> be selected for upgrades automatically (i.e. other slots should be
> preferred).

[facepalm]

Or maybe we should explore the option of fixing python.eclass to not
depend on random python versions implicitly?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-python] Python 3 in Gentoo

[Dirkjan Ochtman]

On Mon, Jul 30, 2012 at 11:06 AM, Michał Górny <mgorny@gentoo.org> wrote:
>> Well, maybe we should explore that option. It would seem to solve a
>> real problem that doesn't just apply to python. For example, the SLOT
>> value could be prefixed with something to indicate that it should not
>> be selected for upgrades automatically (i.e. other slots should be
>> preferred).
>
> [facepalm]

Well, thanks for your constructive participation in this discussion.

> Or maybe we should explore the option of fixing python.eclass to not
> depend on random python versions implicitly?

I don't know that it does, but I hope you can enlighten me!

Cheers,

Dirkjan

Re: [gentoo-python] Python 3 in Gentoo

[Michał Górny]

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

On Mon, 30 Jul 2012 11:09:11 +0200
Dirkjan Ochtman <djc@gentoo.org> wrote:

> On Mon, Jul 30, 2012 at 11:06 AM, Michał Górny <mgorny@gentoo.org>
> wrote:
> >> Well, maybe we should explore that option. It would seem to solve a
> >> real problem that doesn't just apply to python. For example, the
> >> SLOT value could be prefixed with something to indicate that it
> >> should not be selected for upgrades automatically (i.e. other
> >> slots should be preferred).
> >
> > [facepalm]
> 
> Well, thanks for your constructive participation in this discussion.

You're saying 'we should explore the option not to upgrade packages
without user explicitly saying "please upgrade this package"'.

> > Or maybe we should explore the option of fixing python.eclass to not
> > depend on random python versions implicitly?
> 
> I don't know that it does, but I hope you can enlighten me!

It does depend on python versions based on $USE_PYTHON. And USE_PYTHON
defaults to 2+3 if installed. If it pulls in Python 3, it will pull in
all the time unless you set USE_PYTHON manually and remerge all
the packages manually.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-python] Python 3 in Gentoo

[Dirkjan Ochtman]

On Mon, Jul 30, 2012 at 11:16 AM, Michał Górny <mgorny@gentoo.org> wrote:
> You're saying 'we should explore the option not to upgrade packages
> without user explicitly saying "please upgrade this package"'.

Yes, or until the package maintainer removes the annotation again.

>> > Or maybe we should explore the option of fixing python.eclass to not
>> > depend on random python versions implicitly?
>>
>> I don't know that it does, but I hope you can enlighten me!
>
> It does depend on python versions based on $USE_PYTHON. And USE_PYTHON
> defaults to 2+3 if installed. If it pulls in Python 3, it will pull in
> all the time unless you set USE_PYTHON manually and remerge all
> the packages manually.

It seems to me that we could fix USE_PYTHON to always depend only on 2
unless it's explicitly set by the user, but it seems to me that
Portage would, in that case, still pull python3 into the stages.

Cheers,

Dirkjan

Re: [gentoo-python] Python 3 in Gentoo

[Michał Górny]

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

On Mon, 30 Jul 2012 11:23:31 +0200
Dirkjan Ochtman <djc@gentoo.org> wrote:

> On Mon, Jul 30, 2012 at 11:16 AM, Michał Górny <mgorny@gentoo.org>
> wrote:
> > You're saying 'we should explore the option not to upgrade packages
> > without user explicitly saying "please upgrade this package"'.
> 
> Yes, or until the package maintainer removes the annotation again.
> 
> >> > Or maybe we should explore the option of fixing python.eclass to
> >> > not depend on random python versions implicitly?
> >>
> >> I don't know that it does, but I hope you can enlighten me!
> >
> > It does depend on python versions based on $USE_PYTHON. And
> > USE_PYTHON defaults to 2+3 if installed. If it pulls in Python 3,
> > it will pull in all the time unless you set USE_PYTHON manually and
> > remerge all the packages manually.
> 
> It seems to me that we could fix USE_PYTHON to always depend only on 2
> unless it's explicitly set by the user, but it seems to me that
> Portage would, in that case, still pull python3 into the stages.

Portage will pull python3 if and only if anything depends on python:3.*
or anything depends on python without a SLOT (or either is in @world).
If you want it not there, you have to make sure the deps explicitly
state it.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-python] Python 3 in Gentoo

[Dirkjan Ochtman]

On Mon, Jul 30, 2012 at 11:50 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Portage will pull python3 if and only if anything depends on python:3.*
> or anything depends on python without a SLOT (or either is in @world).
> If you want it not there, you have to make sure the deps explicitly
> state it.

So how did python3 end up in the stages again, exactly?

Cheers,

Dirkjan

Re: [gentoo-python] Python 3 in Gentoo

[Matthew Summers]

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

On Mon, Jul 30, 2012 at 6:56 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:

> On Mon, Jul 30, 2012 at 11:50 AM, Michał Górny <mgorny@gentoo.org> wrote:
> > Portage will pull python3 if and only if anything depends on python:3.*
> > or anything depends on python without a SLOT (or either is in @world).
> > If you want it not there, you have to make sure the deps explicitly
> > state it.
>
> So how did python3 end up in the stages again, exactly?
>
> Cheers,
>
> Dirkjan
>
>
Dirkjan, I believe it is portage that pulls in python:3, since by default
it prefers the latest stable version.

-- 
Matthew W. Summers
Gentoo Foundation Inc.

[-- Attachment #2: Type: text/html, Size: 1034 bytes --]

Re: [gentoo-python] Python 3 in Gentoo

[Matthew Summers]

Seems to me that the easiest way to manage this would be to set
USE="python2" for portage in the profile, IFF you want to prevent
python:3 in the stages.

That said, I don't see what the real issue is here. Those that want
python:2 and/or python:3 will set USE_PYTHON correctly. I am concerned
here that a vocal minority will cause some invasive change that the
silent majority cares little about. Some may find the current status
annoying, others will find the change annoying (me being one of the
latter).

Unless someone can provide empirical data to backup any claim, one way
or the other, I would strongly suggest that no change be made,
especially without further consultation regarding the _proposed_
change with the developer and user communities.

Thank you for your consideration.

Matt
--
Matthew W. Summers
Gentoo Foundation Inc.

Re: [gentoo-python] Python 3 in Gentoo

[Nikolaj Sjujskij]

> Seems to me that the easiest way to manage this would be to set
> USE="python2" for portage in the profile, IFF you want to prevent
> python:3 in the stages.
>
> That said, I don't see what the real issue is here. Those that want
> python:2 and/or python:3 will set USE_PYTHON correctly. I am concerned
> here that a vocal minority will cause some invasive change that the
> silent majority cares little about. Some may find the current status
> annoying, others will find the change annoying (me being one of the
> latter).
>
> Unless someone can provide empirical data to backup any claim, one way
> or the other, I would strongly suggest that no change be made,
> especially without further consultation regarding the _proposed_
> change with the developer and user communities.
>
> Thank you for your consideration.
    I as a user could only +1. I can't see the issue, honestly. Those who
don't like Python 3, could jolly well mask it and tweak USE_PYTHON /
PYTHON_TARGETS vars. Using this ugly debianish `python3-3.2` or whatever
is a step back in my opinion. Quite a lot of users could kepp their
systems Python2-less. About half of Python modules (at least) work with
both Python 2 and 3. Heck, even Qt3 and Qt4 were one slotted package!

Re: [gentoo-python] Python 3 in Gentoo

[Jesus Rivero (Neurogeek)]

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

On Jul 30, 2012 9:11 AM, "Matthew Summers" <quantumsummers@gentoo.org>
wrote:
>
> On Mon, Jul 30, 2012 at 6:56 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
>>
>> On Mon, Jul 30, 2012 at 11:50 AM, Michał Górny <mgorny@gentoo.org> wrote:
>> > Portage will pull python3 if and only if anything depends on python:3.*
>> > or anything depends on python without a SLOT (or either is in @world).
>> > If you want it not there, you have to make sure the deps explicitly
>> > state it.
>>
>> So how did python3 end up in the stages again, exactly?
>>
>> Cheers,
>>
>> Dirkjan
>>
>
> Dirkjan, I believe it is portage that pulls in python:3, since by default
it prefers the latest stable version.

IIRC, the only package that pulls python in is portage. And python 3 is
being pulled as it is the latest version available in a slotted package
that can be installed depending on both slots.

I believe we are past the point of no return in transforming python:3 into
dev-lang/python3 as this is going to break things and make life harder for
the python team.

Doesn't portage have a python3 useflag? Can't we change the default
behavior on that flag to (or unset it in catalyst) to make it prefer
python2?

>
> --
> Matthew W. Summers
> Gentoo Foundation Inc.
>

[-- Attachment #2: Type: text/html, Size: 1683 bytes --]

Re: [gentoo-python] Python 3 in Gentoo

[Michał Górny]

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

On Mon, 30 Jul 2012 08:11:09 -0500
Matthew Summers <quantumsummers@gentoo.org> wrote:

> On Mon, Jul 30, 2012 at 6:56 AM, Dirkjan Ochtman <djc@gentoo.org>
> wrote:
> 
> > On Mon, Jul 30, 2012 at 11:50 AM, Michał Górny <mgorny@gentoo.org>
> > wrote:
> > > Portage will pull python3 if and only if anything depends on
> > > python:3.* or anything depends on python without a SLOT (or
> > > either is in @world). If you want it not there, you have to make
> > > sure the deps explicitly state it.
> >
> > So how did python3 end up in the stages again, exactly?
> >
> > Cheers,
> >
> > Dirkjan
> >
> >
> Dirkjan, I believe it is portage that pulls in python:3, since by
> default it prefers the latest stable version.

No. As you can see in the ebuild, it pulls python2 by default. To pull
in python3, you have to USE=python3.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-python] Python 3 in Gentoo

[Jesus Rivero (Neurogeek)]

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

On Jul 30, 2012 9:40 AM, "Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:
>
>
>> Seems to me that the easiest way to manage this would be to set
>> USE="python2" for portage in the profile, IFF you want to prevent
>> python:3 in the stages.
>>
>> That said, I don't see what the real issue is here. Those that want
>> python:2 and/or python:3 will set USE_PYTHON correctly. I am concerned
>> here that a vocal minority will cause some invasive change that the
>> silent majority cares little about. Some may find the current status
>> annoying, others will find the change annoying (me being one of the
>> latter).
>>
>> Unless someone can provide empirical data to backup any claim, one way
>> or the other, I would strongly suggest that no change be made,
>> especially without further consultation regarding the _proposed_
>> change with the developer and user communities.
>>
>> Thank you for your consideration.
>
>    I as a user could only +1. I can't see the issue, honestly. Those who
> don't like Python 3, could jolly well mask it and tweak USE_PYTHON /
> PYTHON_TARGETS vars. Using this ugly debianish `python3-3.2` or whatever

Another thing. PYTHON_TARGETS is set in the gentoo profile as 2.7 3
2 as default. If this is true, can we take 3.2 out and make it a user
opt-in?

I don't think 3.2 is necessary in a lot of systems/use cases.

> is a step back in my opinion. Quite a lot of users could kepp their
> systems Python2-less. About half of Python modules (at least) work with
> both Python 2 and 3. Heck, even Qt3 and Qt4 were one slotted package!
>

[-- Attachment #2: Type: text/html, Size: 1966 bytes --]

Re: [gentoo-python] Python 3 in Gentoo

[Matthew Summers]

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

On Jul 30, 2012 9:04 AM, "Michał Górny" <mgorny@gentoo.org> wrote:
>
> On Mon, 30 Jul 2012 08:11:09 -0500
> Matthew Summers <quantumsummers@gentoo.org> wrote:
>
> > On Mon, Jul 30, 2012 at 6:56 AM, Dirkjan Ochtman <djc@gentoo.org>
> > wrote:
> >
> > > On Mon, Jul 30, 2012 at 11:50 AM, Michał Górny <mgorny@gentoo.org>
> > > wrote:
> > > > Portage will pull python3 if and only if anything depends on
> > > > python:3.* or anything depends on python without a SLOT (or
> > > > either is in @world). If you want it not there, you have to make
> > > > sure the deps explicitly state it.
> > >
> > > So how did python3 end up in the stages again, exactly?
> > >
> > > Cheers,
> > >
> > > Dirkjan
> > >
> > >
> > Dirkjan, I believe it is portage that pulls in python:3, since by
> > default it prefers the latest stable version.
>
> No. As you can see in the ebuild, it pulls python2 by default. To pull
> in python3, you have to USE=python3.
>
> --
> Best regards,
> Michał Górny

So, what happens when you have neither USE python2 or python3 set, as that
is the default. I think that pulls in the latest stable version.

Matt

[-- Attachment #2: Type: text/html, Size: 1698 bytes --]

Re: [gentoo-python] Python 3 in Gentoo

[Michał Górny]

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

On Mon, 30 Jul 2012 09:07:17 -0500
Matthew Summers <quantumsummers@gentoo.org> wrote:

> On Jul 30, 2012 9:04 AM, "Michał Górny" <mgorny@gentoo.org> wrote:
> >
> > On Mon, 30 Jul 2012 08:11:09 -0500
> > Matthew Summers <quantumsummers@gentoo.org> wrote:
> >
> > > On Mon, Jul 30, 2012 at 6:56 AM, Dirkjan Ochtman <djc@gentoo.org>
> > > wrote:
> > >
> > > > On Mon, Jul 30, 2012 at 11:50 AM, Michał Górny
> > > > <mgorny@gentoo.org> wrote:
> > > > > Portage will pull python3 if and only if anything depends on
> > > > > python:3.* or anything depends on python without a SLOT (or
> > > > > either is in @world). If you want it not there, you have to
> > > > > make sure the deps explicitly state it.
> > > >
> > > > So how did python3 end up in the stages again, exactly?
> > > >
> > > > Cheers,
> > > >
> > > > Dirkjan
> > > >
> > > >
> > > Dirkjan, I believe it is portage that pulls in python:3, since by
> > > default it prefers the latest stable version.
> >
> > No. As you can see in the ebuild, it pulls python2 by default. To
> > pull in python3, you have to USE=python3.
> >
> > --
> > Best regards,
> > Michał Górny
> 
> So, what happens when you have neither USE python2 or python3 set, as
> that is the default. I think that pulls in the latest stable version.

Ah, sorry, my bad. I took '-2.7' for ':2.7'. Then you are indeed right.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-python] Python 3 in Gentoo

[Mike Gilbert]

On Mon, Jul 30, 2012 at 3:36 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> I agree that installing both is probably overkill for most users. I
> think the solution is somewhere outside the dev-lang/python package,
> though, in having the system set or portage or whatever the hell it is
> that first pulls in python prefer python-2.

I looked into this, and there are currently two things that will pull
python-3 into a stage3:

1. sys-apps/portage due to its >=dev-lang/python-2.7[ssl] dependency.
2. app-admin/python-updater has a bare "dev-lang/python" dependency.

I have verified that if you install python:2.7, and adjust those
dependencies to the following, portage will no longer try to pull in
python-3.2 on a world update.

sys-apps/portage:

DEPEND="|| ( =dev-lang/python-3*[ssl] dev-lang/python:2.7[ssl]
dev-lang/python:2.6[threads,ssl] )"

app-admin/python-updater:

DEPEND="|| ( dev-lang/python-3* dev-lang/python-2* )"

The || deps are key here; this causes portage to weight an already
installed package over the rest.

In fact, if you reverse the order of python-3 and python-2, that
SHOULD cause python-2 to be pulled into the stage building process
instead of python-3.

So, another possible alternative here is to scour the tree, replacing
any dependencies on dev-lang/python with || deps. I believe
python.eclass would also need to be updated. Does that sound like an
acceptable solution?

Re: [gentoo-python] Python 3 in Gentoo

[Dirkjan Ochtman]

On Mon, Jul 30, 2012 at 5:19 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> So, another possible alternative here is to scour the tree, replacing
> any dependencies on dev-lang/python with || deps. I believe
> python.eclass would also need to be updated. Does that sound like an
> acceptable solution?

It sounds pretty messy, but I guess it depends on how many packages
depend on bare dev-lang/python.

I guess I still think it should be possible to give Portage a hint not
to install a new SLOT if the old SLOT is okay.

Cheers,

Dirkjan

Re: [gentoo-python] Python 3 in Gentoo

[Mike Gilbert]

On Mon, Jul 30, 2012 at 11:22 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> On Mon, Jul 30, 2012 at 5:19 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>> So, another possible alternative here is to scour the tree, replacing
>> any dependencies on dev-lang/python with || deps. I believe
>> python.eclass would also need to be updated. Does that sound like an
>> acceptable solution?
>
> It sounds pretty messy, but I guess it depends on how many packages
> depend on bare dev-lang/python.
>
> I guess I still think it should be possible to give Portage a hint not
> to install a new SLOT if the old SLOT is okay.
>

In this case, I think we would need something more subtle than that;
most users would want a hypothetical python-2.8 to be installed, and
python-3 users will certainly want to be upgraded to python-3.3 when
that lands.

In other words, if we tell portage not to upgrade to a new slot
automatically, that means users would have to manually install each
major release of python.

I think this would be much simpler if we only slotted python on the
major version (2 or 3), but I'm sure there are many users who would
object to that (myself included).

Re: [gentoo-python] Python 3 in Gentoo

[Dirkjan Ochtman]

On Mon, Jul 30, 2012 at 5:30 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>> I guess I still think it should be possible to give Portage a hint not
>> to install a new SLOT if the old SLOT is okay.
>
> In this case, I think we would need something more subtle than that;
> most users would want a hypothetical python-2.8 to be installed, and
> python-3 users will certainly want to be upgraded to python-3.3 when
> that lands.
>
> In other words, if we tell portage not to upgrade to a new slot
> automatically, that means users would have to manually install each
> major release of python.

No, I was going for the kind of effect where being inclusive wrt the
new major Python version would be controlled in a single place. I.e.
in the ebuild or in an eclass or some such.

So you'd have SLOT="~3" in the python-3* ebuilds, and Portage would
know to not install SLOT=3 unless requested explicitly, and at some
point we'd remove the '~'.

Cheers,

Dirkjan

Re: [gentoo-python] Python 3 in Gentoo

[Mike Gilbert]

On Mon, Jul 30, 2012 at 11:40 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> On Mon, Jul 30, 2012 at 5:30 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>>> I guess I still think it should be possible to give Portage a hint not
>>> to install a new SLOT if the old SLOT is okay.
>>
>> In this case, I think we would need something more subtle than that;
>> most users would want a hypothetical python-2.8 to be installed, and
>> python-3 users will certainly want to be upgraded to python-3.3 when
>> that lands.
>>
>> In other words, if we tell portage not to upgrade to a new slot
>> automatically, that means users would have to manually install each
>> major release of python.
>
> No, I was going for the kind of effect where being inclusive wrt the
> new major Python version would be controlled in a single place. I.e.
> in the ebuild or in an eclass or some such.
>
> So you'd have SLOT="~3" in the python-3* ebuilds, and Portage would
> know to not install SLOT=3 unless requested explicitly, and at some
> point we'd remove the '~'.

Where else in the tree could this concept be applied?

I would prefer to avoid going through the EAPI process if it is just
going to be used for python. And even then, I'm not really excited
about the prospect of explaining it.

Also, I'm sure that people will whine about the "upgrade path" being
broken if we set EAPI=5 or 6 in the python ebuilds any time this
decade.

A solution that works within the confines of the current EAPI spec
should be greatly preferred.

Re: [gentoo-python] Python 3 in Gentoo

[Matthew Summers]

On Mon, Jul 30, 2012 at 10:56 AM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Mon, Jul 30, 2012 at 11:40 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
>> On Mon, Jul 30, 2012 at 5:30 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>>>> I guess I still think it should be possible to give Portage a hint not
>>>> to install a new SLOT if the old SLOT is okay.
>>>
>>> In this case, I think we would need something more subtle than that;
>>> most users would want a hypothetical python-2.8 to be installed, and
>>> python-3 users will certainly want to be upgraded to python-3.3 when
>>> that lands.
>>>
>>> In other words, if we tell portage not to upgrade to a new slot
>>> automatically, that means users would have to manually install each
>>> major release of python.
>>
>> No, I was going for the kind of effect where being inclusive wrt the
>> new major Python version would be controlled in a single place. I.e.
>> in the ebuild or in an eclass or some such.
>>
>> So you'd have SLOT="~3" in the python-3* ebuilds, and Portage would
>> know to not install SLOT=3 unless requested explicitly, and at some
>> point we'd remove the '~'.
>
> Where else in the tree could this concept be applied?
>
> I would prefer to avoid going through the EAPI process if it is just
> going to be used for python. And even then, I'm not really excited
> about the prospect of explaining it.
>
> Also, I'm sure that people will whine about the "upgrade path" being
> broken if we set EAPI=5 or 6 in the python ebuilds any time this
> decade.
>
> A solution that works within the confines of the current EAPI spec
> should be greatly preferred.
>

Could we not just set a dep as =dev-lang/python:2 so that any version
of python-2.* would satisfy the dep? Or, would this cause issues in
avoiding old versions of python (python-2.5)? It might be enough to
change the portage ebuild to work as it does now for the USE python2
and python3, but in the case where those flags are not set, then just
pull in python:2 which would yield the latest stable version of
python-2.*

I think adding something to EAPI is going to take too long and/or not
work well for folks.

For python-updater, I might be inclined to add similar USE to portage
to manage the deps.

-- 
Matthew W. Summers
Gentoo Foundation Inc.

Re: [gentoo-python] Python 3 in Gentoo

[Mike Gilbert]

On Mon, Jul 30, 2012 at 12:05 PM, Matthew Summers
<quantumsummers@gentoo.org> wrote:
> Could we not just set a dep as =dev-lang/python:2 so that any version
> of python-2.* would satisfy the dep? Or, would this cause issues in
> avoiding old versions of python (python-2.5)? It might be enough to
> change the portage ebuild to work as it does now for the USE python2
> and python3, but in the case where those flags are not set, then just
> pull in python:2 which would yield the latest stable version of
> python-2.*

Using an || dep with to separate =dev-lang/python-2* and
=dev-lang/python-3* (or something roughly equivalent) is enough to
trigger the desired behavior from portage. See my previous message in
this thread.

> For python-updater, I might be inclined to add similar USE to portage
> to manage the deps.

No need for the use-flags. Again, I think the || dep is sufficient.

Re: [gentoo-python] Python 3 in Gentoo

[Matthew Summers]

On Mon, Jul 30, 2012 at 11:16 AM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Mon, Jul 30, 2012 at 12:05 PM, Matthew Summers
> <quantumsummers@gentoo.org> wrote:
>> Could we not just set a dep as =dev-lang/python:2 so that any version
>> of python-2.* would satisfy the dep? Or, would this cause issues in
>> avoiding old versions of python (python-2.5)? It might be enough to
>> change the portage ebuild to work as it does now for the USE python2
>> and python3, but in the case where those flags are not set, then just
>> pull in python:2 which would yield the latest stable version of
>> python-2.*
>
> Using an || dep with to separate =dev-lang/python-2* and
> =dev-lang/python-3* (or something roughly equivalent) is enough to
> trigger the desired behavior from portage. See my previous message in
> this thread.
>
>> For python-updater, I might be inclined to add similar USE to portage
>> to manage the deps.
>
> No need for the use-flags. Again, I think the || dep is sufficient.
>

Yes, that makes sense, its a matter of order then.

-- 
Matthew W. Summers
Gentoo Foundation Inc.

Re: [gentoo-python] Python 3 in Gentoo

[Dirkjan Ochtman]

On Mon, Jul 30, 2012 at 5:56 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> Where else in the tree could this concept be applied?

I think php5 was first handled this way? Maybe apache2?
dev-python/jinja2, for sure.

> I would prefer to avoid going through the EAPI process if it is just
> going to be used for python. And even then, I'm not really excited
> about the prospect of explaining it.

Nor am I, really. And may be we should pursue your idea at the same
time. But I think it would sure be nice if we can prevent painting
ourselves into a similar corner a few years down the road.

> A solution that works within the confines of the current EAPI spec
> should be greatly preferred.

So do you know how many ebuilds we'd have to update to get it right?

Cheers,

Dirkjan

Re: [gentoo-python] Python 3 in Gentoo

[Mike Gilbert]

On Mon, Jul 30, 2012 at 12:53 PM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> On Mon, Jul 30, 2012 at 5:56 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>> Where else in the tree could this concept be applied?
>
> I think php5 was first handled this way? Maybe apache2?
> dev-python/jinja2, for sure.
>
>> I would prefer to avoid going through the EAPI process if it is just
>> going to be used for python. And even then, I'm not really excited
>> about the prospect of explaining it.
>
> Nor am I, really. And may be we should pursue your idea at the same
> time. But I think it would sure be nice if we can prevent painting
> ourselves into a similar corner a few years down the road.
>

Ok. I think we will need something a bit more formally defined before
we take such a proposal to a wider audience.

>> A solution that works within the confines of the current EAPI spec
>> should be greatly preferred.
>
> So do you know how many ebuilds we'd have to update to get it right?
>

At the moment, no. If someone could help me write a script to identify
affected packages, that would be great.

If said script uses the portage api to determine the dependency tree,
we will want to modify python.eclass first to reduce the number of
hits. This could be done in a local copy of the tree.

Re: [gentoo-python] Python 3 in Gentoo

[Thomas Sachau]

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

Mike Gilbert schrieb:
> On Mon, Jul 30, 2012 at 3:36 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
>> I agree that installing both is probably overkill for most users. I
>> think the solution is somewhere outside the dev-lang/python package,
>> though, in having the system set or portage or whatever the hell it is
>> that first pulls in python prefer python-2.
> 
> I looked into this, and there are currently two things that will pull
> python-3 into a stage3:
> 
> 1. sys-apps/portage due to its >=dev-lang/python-2.7[ssl] dependency.
> 2. app-admin/python-updater has a bare "dev-lang/python" dependency.
> 
> I have verified that if you install python:2.7, and adjust those
> dependencies to the following, portage will no longer try to pull in
> python-3.2 on a world update.
> 
> sys-apps/portage:
> 
> DEPEND="|| ( =dev-lang/python-3*[ssl] dev-lang/python:2.7[ssl]
> dev-lang/python:2.6[threads,ssl] )"
> 
> app-admin/python-updater:
> 
> DEPEND="|| ( dev-lang/python-3* dev-lang/python-2* )"
> 
> The || deps are key here; this causes portage to weight an already
> installed package over the rest.
> 
> In fact, if you reverse the order of python-3 and python-2, that
> SHOULD cause python-2 to be pulled into the stage building process
> instead of python-3.
> 
> So, another possible alternative here is to scour the tree, replacing
> any dependencies on dev-lang/python with || deps. I believe
> python.eclass would also need to be updated. Does that sound like an
> acceptable solution?
> 
> 

If this prevents python-3 to be pulled in also python-2 does still
satisfies all requirements (for stage3 and for updates), then this looks
like an acceptable solution with less work. It would also mean, that
PYTHON_TARGETS could again just go with python2_7.

The only drawback i see with this solution is, that python dependencies
need to be done carefully, so that noone does accidently pull python-3
in again at some later point.

-- 

Thomas Sachau
Gentoo Linux Developer


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

Re: [gentoo-python] Python 3 in Gentoo

[Nikolaj Sjujskij]

Den 2012-07-30 18:05:38 skrev Jesus Rivero (Neurogeek)  
<neurogeek@gentoo.org>:

> On Jul 30, 2012 9:40 AM, "Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:
>>
>>
>>> Seems to me that the easiest way to manage this would be to set
>>> USE="python2" for portage in the profile, IFF you want to prevent
>>> python:3 in the stages.
>>>
>>> That said, I don't see what the real issue is here. Those that want
>>> python:2 and/or python:3 will set USE_PYTHON correctly. I am concerned
>>> here that a vocal minority will cause some invasive change that the
>>> silent majority cares little about. Some may find the current status
>>> annoying, others will find the change annoying (me being one of the
>>> latter).
>>>
>>> Unless someone can provide empirical data to backup any claim, one way
>>> or the other, I would strongly suggest that no change be made,
>>> especially without further consultation regarding the _proposed_
>>> change with the developer and user communities.
>>>
>>> Thank you for your consideration.
>>
>>    I as a user could only +1. I can't see the issue, honestly. Those who
>> don't like Python 3, could jolly well mask it and tweak USE_PYTHON /
>> PYTHON_TARGETS vars. Using this ugly debianish `python3-3.2` or whatever
>
> Another thing. PYTHON_TARGETS is set in the gentoo profile as 2.7 3
> 2 as default. If this is true, can we take 3.2 out and make it a user
> opt-in?
PYTHON_TARGETS is used only by a few packages, and not that popular ones  
at that (sorry, Michał! They're superb but still not widely known), so  
this variable doesn't implicate things much and default value could be  
tweaked in profile without much fuss and apprehension. If we find a  
sane'n'safe way to drop Python 3 from base system, that is. As far as I  
remember 3.2 was added to default PYTHON_TARGETS value exactly because of  
"stage3 has Python 3 by default".

Re: [gentoo-python] Python 3 in Gentoo

[Ben de Groot]

On 31 July 2012 15:11, Nikolaj Sjujskij <sterkrig@myopera.com> wrote:
> Den 2012-07-30 18:05:38 skrev Jesus Rivero (Neurogeek)
> <neurogeek@gentoo.org>:
> [...] As far as I remember 3.2 was added to default PYTHON_TARGETS value
> exactly because of "stage3 has Python 3 by default".

Otherwise known as "fix the symptoms, not the root problem"...

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-python] Python 3 in Gentoo

[Nikolaj Sjujskij]

Den 2012-07-31 16:09:10 skrev Ben de Groot <yngwin@gentoo.org>:

> On 31 July 2012 15:11, Nikolaj Sjujskij <sterkrig@myopera.com> wrote:
>> Den 2012-07-30 18:05:38 skrev Jesus Rivero (Neurogeek)
>> <neurogeek@gentoo.org>:
>> [...] As far as I remember 3.2 was added to default PYTHON_TARGETS value
>> exactly because of "stage3 has Python 3 by default".
>
> Otherwise known as "fix the symptoms, not the root problem"...
I don't see much of a problem there. Current situation is kinda right in  
my opinion, since it smooths future upgrade to Python 3 (which I consider  
inevitable).

Re: [gentoo-python] Python 3 in Gentoo

[Ben de Groot]

On 31 July 2012 20:14, Nikolaj Sjujskij <sterkrig@myopera.com> wrote:
> Den 2012-07-31 16:09:10 skrev Ben de Groot <yngwin@gentoo.org>:
>
>
>> On 31 July 2012 15:11, Nikolaj Sjujskij <sterkrig@myopera.com> wrote:
>>>
>>> Den 2012-07-30 18:05:38 skrev Jesus Rivero (Neurogeek)
>>> <neurogeek@gentoo.org>:
>>> [...] As far as I remember 3.2 was added to default PYTHON_TARGETS value
>>> exactly because of "stage3 has Python 3 by default".
>>
>>
>> Otherwise known as "fix the symptoms, not the root problem"...
>
> I don't see much of a problem there. Current situation is kinda right in my
> opinion, since it smooths future upgrade to Python 3 (which I consider
> inevitable).

So, because at some undetermined point in the future it would be
smoother to migrate to python-3 as default this way, you want to
burden the great majority of users now with what is for all intents
and purposes to them a useless number of multiple, slotted python
versions?

I see that as a problem. For the great majority of users python:2.7 is
currently, and for the foreseeable future, the best choice. There is a
great number of packages and libraries that don't work with python-3,
and just a handful that don't work with python-2.

It also leads to all kinds of spurious bugs, such as people who have
2.7 set as their default interpreter, but have not removed and masked
>=3.0, so end up with updates, but forget to switch their py3
interpreter to the latest version.

Until such time this situation becomes radically different, we should
make sure users have the best experience, which is python:2.7 by
default, and python-3 only if they explicitly choose to install it.
-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-python] Python 3 in Gentoo

[Mike Gilbert]

On Mon, Jul 30, 2012 at 1:05 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>> So do you know how many ebuilds we'd have to update to get it right?
>>
>
> At the moment, no. If someone could help me write a script to identify
> affected packages, that would be great.
>
> If said script uses the portage api to determine the dependency tree,
> we will want to modify python.eclass first to reduce the number of
> hits. This could be done in a local copy of the tree.

I've created a quick little script and posted it in my devspace. Now I
just need to mess with python.eclass.

http://dev.gentoo.org/~floppym/python-deps.py

Re: [gentoo-python] Python 3 in Gentoo

[Nikolaj Sjujskij]

Den 2012-07-31 18:40:17 skrev Ben de Groot <yngwin@gentoo.org>:

> On 31 July 2012 20:14, Nikolaj Sjujskij <sterkrig@myopera.com> wrote:
>> Den 2012-07-31 16:09:10 skrev Ben de Groot <yngwin@gentoo.org>:
>>
>>
>>> On 31 July 2012 15:11, Nikolaj Sjujskij <sterkrig@myopera.com> wrote:
>>>>
>>>> Den 2012-07-30 18:05:38 skrev Jesus Rivero (Neurogeek)
>>>> <neurogeek@gentoo.org>:
>>>> [...] As far as I remember 3.2 was added to default PYTHON_TARGETS  
>>>> value
>>>> exactly because of "stage3 has Python 3 by default".
>>>
>>>
>>> Otherwise known as "fix the symptoms, not the root problem"...
>>
>> I don't see much of a problem there. Current situation is kinda right  
>> in my
>> opinion, since it smooths future upgrade to Python 3 (which I consider
>> inevitable).
>
> So, because at some undetermined point in the future it would be
> smoother to migrate to python-3 as default this way, you want to
> burden the great majority of users now with what is for all intents
> and purposes to them a useless number of multiple, slotted python
> versions?
>
> I see that as a problem. For the great majority of users python:2.7 is
> currently, and for the foreseeable future, the best choice. There is a
> great number of packages and libraries that don't work with python-3,
> and just a handful that don't work with python-2.
>
> It also leads to all kinds of spurious bugs, such as people who have
> 2.7 set as their default interpreter, but have not removed and masked
>> =3.0, so end up with updates, but forget to switch their py3
> interpreter to the latest version.
>
> Until such time this situation becomes radically different, we should
> make sure users have the best experience, which is python:2.7 by
> default, and python-3 only if they explicitly choose to install it.
That's a valid point, and I don't object if by default there will be no  
Python 3 in Gentoo installation. Provided it'd be accomplished by tweaking  
dependencies of @system without `dev-lang/python3` weirdness. But I regard  
current situation as quite logical and acceptable too.

Re: [gentoo-python] Python 3 in Gentoo

[Mike Gilbert]

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

On Tue, Jul 31, 2012 at 11:31 AM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Mon, Jul 30, 2012 at 1:05 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>>> So do you know how many ebuilds we'd have to update to get it right?
>>>
>>
>> At the moment, no. If someone could help me write a script to identify
>> affected packages, that would be great.
>>
>> If said script uses the portage api to determine the dependency tree,
>> we will want to modify python.eclass first to reduce the number of
>> hits. This could be done in a local copy of the tree.
>
> I've created a quick little script and posted it in my devspace. Now I
> just need to mess with python.eclass.
>
> http://dev.gentoo.org/~floppym/python-deps.py

After modifying python.eclass, distutils.eclass, java-ant-2.eclass,
and waf-utils.eclass, there are 532 dependencies that would need to be
modified to make the || dep plan work. I have attached the list for
reference.

Does this seem like a viable option? Is anyone going to volunteer to
take it from here?

[-- Attachment #2: python-deps.txt --]
[-- Type: text/plain, Size: 24349 bytes --]

app-admin/python-updater-0.10 dev-lang/python
app-admin/python-updater-0.10-r2 dev-lang/python
app-admin/python-updater-9999 dev-lang/python
app-arch/cfv-1.18.1 dev-lang/python
app-arch/cfv-1.18.2 dev-lang/python
app-arch/cfv-1.18.3 dev-lang/python
app-arch/rpm-4.9.1.3 >=dev-lang/python-2.3
app-arch/rpm-4.9.1.3 >=dev-lang/python-2.3
app-arch/rpm-4.10.0 >=dev-lang/python-2.3
app-arch/rpm-4.10.0 >=dev-lang/python-2.3
app-arch/rpm5-5.1.6 dev-lang/python
app-arch/rpm5-5.1.6 dev-lang/python
app-cdr/burn-cd-1.7.4 dev-lang/python
app-cdr/burn-cd-1.8.0 dev-lang/python
app-crypt/mit-krb5-1.9.2-r2 dev-lang/python
app-crypt/mit-krb5-1.9.4 dev-lang/python
app-crypt/mit-krb5-1.9.4-r1 dev-lang/python
app-crypt/mit-krb5-1.10.1-r2 dev-lang/python
app-crypt/mit-krb5-1.10.2-r1 dev-lang/python
app-crypt/openssl-blacklist-0.4.1 dev-lang/python
app-crypt/openssl-blacklist-0.4.1 dev-lang/python
app-crypt/openssl-blacklist-0.4.2 dev-lang/python
app-crypt/openssl-blacklist-0.4.2 dev-lang/python
app-crypt/openssl-blacklist-0.5.3 dev-lang/python
app-crypt/openssl-blacklist-0.5.3 dev-lang/python
app-crypt/openvpn-blacklist-0.3 dev-lang/python
app-crypt/openvpn-blacklist-0.3 dev-lang/python
app-crypt/openvpn-blacklist-0.4 dev-lang/python
app-crypt/openvpn-blacklist-0.4 dev-lang/python
app-crypt/ssh-multiadd-1.3.1 >=dev-lang/python-2.0-r3
app-crypt/ssh-multiadd-1.3.1 >=dev-lang/python-2.0-r3
app-doc/doxygen-1.5.4 dev-lang/python
app-doc/doxygen-1.5.4 dev-lang/python
app-doc/doxygen-1.5.8-r1 dev-lang/python
app-doc/doxygen-1.5.8-r1 dev-lang/python
app-doc/doxygen-1.6.3 dev-lang/python
app-doc/doxygen-1.6.3 dev-lang/python
app-doc/doxygen-1.7.2 dev-lang/python
app-doc/doxygen-1.7.2 dev-lang/python
app-doc/doxygen-1.7.3 dev-lang/python
app-doc/doxygen-1.7.3 dev-lang/python
app-doc/doxygen-1.7.5.1 dev-lang/python
app-doc/doxygen-1.7.5.1 dev-lang/python
app-emulation/ganeti-2.5.1 >=dev-lang/python-2.6
app-emulation/ganeti-2.5.1 >=dev-lang/python-2.6
app-emulation/ganeti-2.5.2 >=dev-lang/python-2.6
app-emulation/ganeti-2.5.2 >=dev-lang/python-2.6
app-emulation/ganeti-2.5.2-r1 >=dev-lang/python-2.6
app-emulation/ganeti-2.5.2-r1 >=dev-lang/python-2.6
app-emulation/ganeti-2.6.0 >=dev-lang/python-2.6
app-emulation/ganeti-2.6.0 >=dev-lang/python-2.6
app-emulation/virtualbox-9999 >=dev-lang/python-2.3[threads]
app-emulation/xen-tools-3.4.2-r3 dev-lang/python[ncurses,threads]
app-emulation/xen-tools-3.4.2-r3 dev-lang/python[ssl]
app-emulation/xen-tools-3.4.2-r3 dev-lang/python[ncurses,threads]
app-emulation/xen-tools-3.4.2-r5 dev-lang/python[ncurses,threads]
app-emulation/xen-tools-3.4.2-r5 dev-lang/python[ssl]
app-emulation/xen-tools-3.4.2-r5 dev-lang/python[ncurses,threads]
app-emulation/xen-tools-4.1.1-r5 dev-lang/python
app-emulation/xen-tools-4.1.1-r5 dev-lang/python
app-emulation/xen-tools-4.1.1-r6 dev-lang/python
app-emulation/xen-tools-4.1.1-r6 dev-lang/python
app-emulation/xen-tools-4.1.2-r2 dev-lang/python[ncurses]
app-emulation/xen-tools-4.1.2-r3 dev-lang/python[ncurses]
app-i18n/ibus-anthy-1.2.0.20100115 >=dev-lang/python-2.5
app-i18n/ibus-anthy-1.2.0.20100115 >=dev-lang/python-2.5
app-i18n/ibus-tutcode-1.0.0 >=dev-lang/python-2.5
app-i18n/ibus-tutcode-1.0.0 >=dev-lang/python-2.5
app-i18n/ibus-tutcode-1.0.1 >=dev-lang/python-2.5
app-i18n/ibus-tutcode-1.0.1 >=dev-lang/python-2.5
app-i18n/ibus-tutcode-1.0.2 >=dev-lang/python-2.5
app-i18n/ibus-tutcode-1.0.2 >=dev-lang/python-2.5
app-misc/anki-1.2.11 >=dev-lang/python-2.5[sqlite]
app-misc/anki-1.2.11 >=dev-lang/python-2.5[sqlite]
app-misc/beanstalkd-1.4.6 dev-lang/python
app-misc/beanstalkd-1.4.6-r1 dev-lang/python
app-misc/beanstalkd-1.5 dev-lang/python
app-misc/beanstalkd-1.6 dev-lang/python
app-misc/cwiid-20110107-r1 >=dev-lang/python-2.4
app-misc/klive-0.28 dev-lang/python
app-misc/klive-0.28 dev-lang/python
app-mobilephone/gammu-1.25.0-r1 dev-lang/python
app-mobilephone/gammu-1.25.0-r1 dev-lang/python
app-pda/libopensync-0.22 >=dev-lang/python-2.2
app-pda/libopensync-0.22 >=dev-lang/python-2.2
app-portage/gentoolkit-0.3.0.4-r5 >=dev-lang/python-2.6[xml]
app-portage/gentoolkit-0.3.0.5 >=dev-lang/python-2.6[xml]
app-portage/gentoolkit-0.3.0.6 >=dev-lang/python-2.6[xml]
app-portage/gentoolkit-0.3.0.6-r1 >=dev-lang/python-2.6[xml]
app-portage/gentoolkit-0.3.0.6-r2 >=dev-lang/python-2.6[xml]
app-portage/gentoolkit-0.3.0.6-r3 >=dev-lang/python-2.6[xml]
app-portage/gentoolkit-9999 >=dev-lang/python-2.6[xml]
app-portage/layman-1.4.1 dev-lang/python
app-portage/layman-1.4.1 dev-lang/python
app-portage/layman-1.4.2-r3 dev-lang/python
app-portage/layman-1.4.2-r3 dev-lang/python
app-portage/layman-2.0.0_rc3 dev-lang/python
app-portage/layman-2.0.0_rc3 dev-lang/python
app-portage/layman-9999 dev-lang/python
app-portage/layman-9999 dev-lang/python
app-portage/overlint-0.4.1 >=dev-lang/python-2.7
app-portage/overlint-0.4.1 >=dev-lang/python-2.6
app-portage/overlint-0.4.2 >=dev-lang/python-2.7
app-portage/overlint-0.4.2 >=dev-lang/python-2.6
app-portage/overlint-0.5 >=dev-lang/python-2.7
app-portage/overlint-0.5 >=dev-lang/python-2.6
app-portage/overlint-0.5.1 >=dev-lang/python-2.7
app-portage/overlint-0.5.1 >=dev-lang/python-2.6
app-portage/overlint-0.5.2 >=dev-lang/python-2.7
app-portage/overlint-0.5.2 >=dev-lang/python-2.6
app-shells/autojump-20.9 dev-lang/python
app-text/asciidoc-8.2.6 >=dev-lang/python-2.3
app-text/asciidoc-8.2.6 >=dev-lang/python-2.3
app-text/txt2tags-2.6 dev-lang/python
app-text/txt2tags-2.6 dev-lang/python
app-text/xlsx2csv-0.16 dev-lang/python[xml]
app-text/xlsx2csv-0.16 dev-lang/python[xml]
app-vim/automatictexplugin-11 >=dev-lang/python-2.7
app-vim/automatictexplugin-11.1 >=dev-lang/python-2.7
app-vim/conque-2.3 >=dev-lang/python-2.3
app-vim/gundo-2.2.2 >=dev-lang/python-2.4
app-vim/gundo-2.4.0 >=dev-lang/python-2.4
app-vim/slimv-0.9.2 >=dev-lang/python-2.4
app-vim/slimv-0.9.7 >=dev-lang/python-2.4
app-vim/threesome-0.2.0 >=dev-lang/python-2.5
dev-cpp/gtest-1.4.0 dev-lang/python
dev-embedded/libftdi-0.17 dev-lang/python
dev-embedded/libftdi-0.17 dev-lang/python
dev-embedded/libftdi-0.18 dev-lang/python
dev-embedded/libftdi-0.18 dev-lang/python
dev-embedded/libftdi-0.19 dev-lang/python
dev-embedded/libftdi-0.19 dev-lang/python
dev-embedded/libftdi-0.20 dev-lang/python
dev-embedded/libftdi-0.20 dev-lang/python
dev-embedded/libftdi-9999 dev-lang/python
dev-embedded/libftdi-9999 dev-lang/python
dev-embedded/libftdi-9999.1.0 dev-lang/python
dev-embedded/libftdi-9999.1.0 dev-lang/python
dev-libs/Ice-3.2.0 >=dev-lang/python-2.4
dev-libs/Ice-3.2.1 >=dev-lang/python-2.4
dev-libs/Ice-3.3.1 >=dev-lang/python-2.4
dev-libs/Ice-3.3.1-r1 >=dev-lang/python-2.4
dev-libs/boost-1.35.0-r2 dev-lang/python
dev-libs/boost-1.35.0-r2 dev-lang/python
dev-libs/boost-1.35.0-r5 dev-lang/python
dev-libs/boost-1.35.0-r5 dev-lang/python
dev-libs/boost-1.37.0-r1 dev-lang/python
dev-libs/boost-1.37.0-r1 dev-lang/python
dev-libs/boost-1.39.0 dev-lang/python
dev-libs/boost-1.39.0 dev-lang/python
dev-libs/boost-1.41.0-r3 dev-lang/python
dev-libs/boost-1.41.0-r3 dev-lang/python
dev-libs/boost-1.42.0 dev-lang/python
dev-libs/boost-1.42.0 dev-lang/python
dev-libs/boost-1.42.0-r1 dev-lang/python
dev-libs/boost-1.42.0-r1 dev-lang/python
dev-libs/boost-1.42.0-r2 dev-lang/python
dev-libs/boost-1.42.0-r2 dev-lang/python
dev-libs/boost-1.45.0 dev-lang/python
dev-libs/boost-1.45.0 dev-lang/python
dev-libs/boost-1.46.1-r1 dev-lang/python
dev-libs/boost-1.46.1-r1 dev-lang/python
dev-libs/boost-1.47.0 dev-lang/python
dev-libs/boost-1.47.0 dev-lang/python
dev-libs/boost-1.47.0-r1 dev-lang/python
dev-libs/boost-1.47.0-r1 dev-lang/python
dev-libs/distorm64-1.7.30-r1 >=dev-lang/python-2.4
dev-libs/distorm64-1.7.30-r1 >=dev-lang/python-2.4
dev-libs/libnatspec-0.2.6 >=dev-lang/python-2.3
dev-libs/libnatspec-0.2.6 >=dev-lang/python-2.3
dev-libs/stfl-0.22 dev-lang/python
dev-libs/stfl-0.22 dev-lang/python
dev-libs/zziplib-0.13.60 >=dev-lang/python-2.4
dev-lisp/abcl-0.0.9-r1 dev-lang/python
dev-perl/Inline-Python-0.390.0 dev-lang/python
dev-perl/Inline-Python-0.390.0 dev-lang/python
dev-perl/Inline-Python-0.400.0 dev-lang/python
dev-perl/Inline-Python-0.400.0 dev-lang/python
dev-python/amara-2.0.0_alpha6 dev-lang/python[wide-unicode]
dev-python/amara-2.0.0_alpha6 dev-lang/python[wide-unicode]
dev-python/compizconfig-python-0.8.4 >=dev-lang/python-2.4
dev-python/compizconfig-python-0.8.4 >=dev-lang/python-2.4
dev-python/couchdb-python-0.6.1 >=dev-lang/python-2.6
dev-python/couchdb-python-0.7 >=dev-lang/python-2.6
dev-python/couchdb-python-0.8 >=dev-lang/python-2.6
dev-python/ipython-0.12-r1 >=dev-lang/python-3.2
dev-python/ipython-0.12-r1 >=dev-lang/python-3.2
dev-python/ipython-0.12.1 >=dev-lang/python-3.2
dev-python/ipython-0.12.1 >=dev-lang/python-3.2
dev-python/ipython-0.13 >=dev-lang/python-3.2
dev-python/ipython-0.13 >=dev-lang/python-3.2
dev-python/pydb-1.26 >=dev-lang/python-2.4.0
dev-python/pydb-1.26 >=dev-lang/python-2.4.0
dev-python/sqlalchemy-0.7.4 >=dev-lang/python-2.5[sqlite]
dev-python/sqlalchemy-0.7.4 >=dev-lang/python-2.5[sqlite]
dev-python/sqlalchemy-0.7.4 >=dev-lang/python-2.5[sqlite]
dev-python/sqlalchemy-0.7.5 >=dev-lang/python-2.5[sqlite]
dev-python/sqlalchemy-0.7.5 >=dev-lang/python-2.5[sqlite]
dev-python/sqlalchemy-0.7.5 >=dev-lang/python-2.5[sqlite]
dev-python/sqlalchemy-0.7.6 >=dev-lang/python-2.5[sqlite]
dev-python/sqlalchemy-0.7.6 >=dev-lang/python-2.5[sqlite]
dev-python/sqlalchemy-0.7.6 >=dev-lang/python-2.5[sqlite]
dev-python/sqlalchemy-0.7.7 >=dev-lang/python-2.5[sqlite]
dev-python/sqlalchemy-0.7.7 >=dev-lang/python-2.5[sqlite]
dev-python/sqlalchemy-0.7.7 >=dev-lang/python-2.5[sqlite]
dev-python/sqlalchemy-0.7.8 >=dev-lang/python-2.5[sqlite]
dev-python/sqlalchemy-0.7.8 >=dev-lang/python-2.5[sqlite]
dev-python/sqlalchemy-0.7.8 >=dev-lang/python-2.5[sqlite]
dev-python/ws4py-0.2.1-r2 dev-lang/python[threads?]
dev-python/ws4py-0.2.2 dev-lang/python[threads?]
dev-python/ws4py-0.2.2 dev-lang/python[threads?]
dev-python/ws4py-9999 dev-lang/python[threads?]
dev-python/ws4py-9999 dev-lang/python[threads?]
dev-util/aap-1.076 >=dev-lang/python-1.5
dev-util/aap-1.090 >=dev-lang/python-1.5
dev-util/aap-1.091 >=dev-lang/python-1.5
dev-util/bam-0.4.0 dev-lang/python
dev-util/bam-0.4.0 dev-lang/python
dev-util/boost-build-1.34.1 dev-lang/python
dev-util/boost-build-1.35.0-r1 dev-lang/python
dev-util/boost-build-1.35.0-r1 dev-lang/python
dev-util/boost-build-1.35.0-r2 dev-lang/python
dev-util/boost-build-1.35.0-r2 dev-lang/python
dev-util/boost-build-1.37.0 dev-lang/python
dev-util/boost-build-1.37.0 dev-lang/python
dev-util/boost-build-1.39.0 dev-lang/python
dev-util/boost-build-1.39.0 dev-lang/python
dev-util/boost-build-1.40.0 dev-lang/python
dev-util/boost-build-1.40.0 dev-lang/python
dev-util/boost-build-1.41.0 dev-lang/python
dev-util/boost-build-1.41.0 dev-lang/python
dev-util/boost-build-1.42.0 dev-lang/python
dev-util/boost-build-1.42.0 dev-lang/python
dev-util/boost-build-1.45.0 dev-lang/python
dev-util/boost-build-1.45.0 dev-lang/python
dev-util/boost-build-1.46.1 dev-lang/python
dev-util/boost-build-1.46.1 dev-lang/python
dev-util/boost-build-1.47.0 dev-lang/python
dev-util/boost-build-1.47.0 dev-lang/python
dev-util/catalyst-2.0.7.1 dev-lang/python
dev-util/catalyst-2.0.7.1-r1 dev-lang/python
dev-util/imediff2-1.1.2-r1 dev-lang/python
dev-util/imediff2-1.1.2-r1 dev-lang/python
dev-util/imediff2-1.1.2-r2 dev-lang/python[ncurses]
dev-util/imediff2-1.1.2-r2 dev-lang/python[ncurses]
dev-util/rootstrap-0.3.24 dev-lang/python
dev-util/rootstrap-0.3.24 dev-lang/python
dev-util/telepathy-inspector-0.5.3 dev-lang/python
dev-vcs/svneverever-1.1.0 >=dev-lang/python-2.7
dev-vcs/svneverever-1.1.0 >=dev-lang/python-2.6
dev-vcs/svneverever-1.2.0 >=dev-lang/python-2.7
dev-vcs/svneverever-1.2.0 >=dev-lang/python-2.6
dev-vcs/svneverever-1.2.1 >=dev-lang/python-2.7
dev-vcs/svneverever-1.2.1 >=dev-lang/python-2.6
games-board/gnubg-20101126 dev-lang/python
games-board/gnubg-20101126 dev-lang/python
games-mud/wxmud-9999 >=dev-lang/python-2.4
games-mud/wxmud-9999 >=dev-lang/python-2.4
games-puzzle/angrydd-1.0.1 >=dev-lang/python-2.3
games-puzzle/angrydd-1.0.1 >=dev-lang/python-2.3
games-rpg/freedroidrpg-0.15 dev-lang/python
gnome-extra/gnome-dvb-daemon-0.2.5 >=dev-lang/python-2.5
gnome-extra/gnome-dvb-daemon-0.2.5 >=dev-lang/python-2.5
gnome-extra/hamster-applet-2.32.1 >=dev-lang/python-2.5[sqlite]
gnome-extra/hamster-applet-2.32.1 >=dev-lang/python-2.5[sqlite]
kde-misc/semantik-0.7.3_p20091013 dev-lang/python
kde-misc/semantik-0.7.3_p20091013 dev-lang/python[xml]
kde-misc/synaptiks-0.8.1 >=dev-lang/python-2.7
kde-misc/synaptiks-0.8.1 >=dev-lang/python-2.7
mail-client/claws-mail-python-0.9 >=dev-lang/python-2.5
mail-client/claws-mail-python-0.9 >=dev-lang/python-2.5
mail-client/claws-mail-python-0.10 >=dev-lang/python-2.5
mail-client/claws-mail-python-0.10 >=dev-lang/python-2.5
mail-filter/ask-2.4.1 >=dev-lang/python-2.2
mail-filter/ask-2.5.3 dev-lang/python
media-gfx/asymptote-2.13 dev-lang/python
media-gfx/asymptote-2.13 dev-lang/python
media-gfx/asymptote-2.15 dev-lang/python
media-gfx/asymptote-2.15 dev-lang/python
media-gfx/asymptote-2.16 dev-lang/python
media-gfx/asymptote-2.16 dev-lang/python
media-gfx/exiv2-0.19 dev-lang/python
media-gfx/fontforge-20100501 dev-lang/python
media-gfx/fontforge-20100501 dev-lang/python
media-gfx/inkscape-0.48.2 dev-lang/python[xml]
media-gfx/inkscape-0.48.2 dev-lang/python[xml]
media-gfx/k3d-0.7.11.0-r1 >=dev-lang/python-2.3
media-gfx/k3d-0.7.11.0-r1 >=dev-lang/python-2.3
media-gfx/yablex-20030826 dev-lang/python
media-libs/clutter-gst-1.0.0 dev-lang/python
media-libs/libkate-0.3.7 dev-lang/python
media-libs/libkate-0.3.8 dev-lang/python
media-libs/libkate-0.4.1 dev-lang/python
media-libs/ming-0.4.3-r1 dev-lang/python
media-libs/ming-0.4.3-r2 dev-lang/python
media-libs/ming-0.4.4 dev-lang/python
media-sound/a2jmidid-4 dev-lang/python
media-sound/a2jmidid-5 dev-lang/python
media-sound/a2jmidid-6 dev-lang/python
media-sound/codecgraph-20090522 dev-lang/python
media-sound/codecgraph-20090522 dev-lang/python
media-sound/dir2ogg-0.11.6 dev-lang/python
media-sound/dir2ogg-0.11.8-r1 >=dev-lang/python-2.5
media-sound/ecasound-2.6.0 dev-lang/python
media-sound/ecasound-2.6.0 dev-lang/python
media-sound/ecasound-2.6.0 dev-lang/python
media-sound/ecasound-2.6.0 dev-lang/python
media-sound/edna-0.5-r4 >=dev-lang/python-2.5
media-sound/edna-0.5-r4 >=dev-lang/python-2.5
media-sound/edna-0.6 >=dev-lang/python-2.5
media-sound/edna-0.6 >=dev-lang/python-2.5
media-sound/lash-0.5.4-r1 dev-lang/python
media-sound/lash-0.5.4-r1 dev-lang/python
media-sound/lilycomp-1.0.2-r1 dev-lang/python[tk]
media-sound/lilycomp-1.0.2-r1 dev-lang/python[tk]
media-sound/moosic-1.5.0 dev-lang/python
media-sound/moosic-1.5.0 dev-lang/python
media-sound/rhythmbox-0.12.8-r1 >=dev-lang/python-2.5
media-sound/rhythmbox-0.12.8-r1 >=dev-lang/python-2.5
media-sound/shoutcast-search-0.3 >=dev-lang/python-2.4
media-sound/shoutcast-search-0.3 >=dev-lang/python-2.4
media-sound/xmms2-0.8-r1 dev-lang/python
media-sound/xmms2-0.8-r1 dev-lang/python
media-sound/xmms2-0.8-r1 dev-lang/python
media-tv/xbmc-11.0 >=dev-lang/python-2.4
media-tv/xbmc-11.0 >=dev-lang/python-2.4
media-tv/xbmc-9999 >=dev-lang/python-2.4
media-tv/xbmc-9999 >=dev-lang/python-2.4
media-video/mplayer2-2.0_p20120309 dev-lang/python
media-video/mplayer2-9999 dev-lang/python
media-video/winki-0.4.5 >=dev-lang/python-2.3
media-video/winki-0.4.5 >=dev-lang/python-2.3
net-analyzer/portbunny-1.0 dev-lang/python
net-analyzer/portbunny-1.0 dev-lang/python
net-analyzer/portbunny-1.0_p20080423 dev-lang/python
net-analyzer/portbunny-1.0_p20080423 dev-lang/python
net-dialup/capisuite-0.4.5-r5 dev-lang/python
net-dialup/capisuite-0.4.5-r5 dev-lang/python
net-dialup/capisuite-0.4.5-r6 dev-lang/python
net-dialup/capisuite-0.4.5-r6 dev-lang/python
net-dialup/freeradius-2.1.11-r1 dev-lang/python
net-dialup/freeradius-2.1.11-r1 dev-lang/python
net-dialup/freeradius-2.1.12 dev-lang/python
net-dialup/freeradius-2.1.12 dev-lang/python
net-firewall/dshieldpy-3.2 dev-lang/python
net-fs/samba-4.0.0_alpha17 >=dev-lang/python-2.4.2
net-fs/samba-4.0.0_alpha17 >=dev-lang/python-2.4.2
net-im/ekg-1.7 dev-lang/python
net-im/ekg-1.7 dev-lang/python
net-im/ekg-1.8_rc1 dev-lang/python
net-im/ekg-1.8_rc1 dev-lang/python
net-im/ekg-1.8_rc1-r1 dev-lang/python
net-im/ekg-1.8_rc1-r1 dev-lang/python
net-im/ekg2-0.3.1-r1 dev-lang/python
net-im/ekg2-0.3.1-r1 dev-lang/python
net-im/ekg2-9999 dev-lang/python
net-im/ekg2-9999 dev-lang/python
net-im/imcom-1.32 >=dev-lang/python-2.2
net-im/imcom-1.32 >=dev-lang/python-2.2
net-im/imcom-1.33 >=dev-lang/python-2.2
net-im/imcom-1.33 >=dev-lang/python-2.2
net-im/imcom-1.34 >=dev-lang/python-2.2
net-im/imcom-1.34 >=dev-lang/python-2.2
net-irc/irssi-otr-0.2 dev-lang/python
net-irc/irssi-otr-0.3 dev-lang/python
net-irc/xchat-2.8.6-r2 >=dev-lang/python-2.2
net-irc/xchat-2.8.6-r2 >=dev-lang/python-2.2
net-irc/xchat-otr-0.3 dev-lang/python
net-libs/libmapi-0.9 dev-lang/python
net-libs/libmapi-0.9 dev-lang/python
net-mail/mailman-2.1.9-r3 >=dev-lang/python-2.3
net-mail/mailman-2.1.9-r3 >=dev-lang/python-2.3
net-mail/mailman-2.1.11 >=dev-lang/python-2.3
net-mail/mailman-2.1.11 >=dev-lang/python-2.3
net-mail/mailman-2.1.12 >=dev-lang/python-2.3
net-mail/mailman-2.1.12 >=dev-lang/python-2.3
net-mail/mailman-2.1.13 >=dev-lang/python-2.3
net-mail/mailman-2.1.13 >=dev-lang/python-2.3
net-mail/mailman-2.1.14_rc1 >=dev-lang/python-2.3
net-mail/mailman-2.1.14_rc1 >=dev-lang/python-2.3
net-mail/mailman-2.1.14 >=dev-lang/python-2.3
net-mail/mailman-2.1.14 >=dev-lang/python-2.3
net-mail/rss2email-2.65 dev-lang/python
net-mail/rss2email-2.65 dev-lang/python
net-misc/geekcredit-0.019 dev-lang/python
net-misc/geekcredit-0.019 dev-lang/python
net-misc/spice-gtk-0.7.159 dev-lang/python
net-misc/spice-gtk-0.8 dev-lang/python
net-misc/spice-gtk-0.11 dev-lang/python
net-misc/spice-gtk-0.12 dev-lang/python
net-misc/ssh-installkeys-1.4 >=dev-lang/python-2.3
net-misc/ssh-installkeys-1.4 >=dev-lang/python-2.3
net-nntp/inn-2.5.2 dev-lang/python
net-nntp/inn-2.5.2 dev-lang/python
net-nntp/inn-2.5.2-r1 dev-lang/python
net-nntp/inn-2.5.2-r1 dev-lang/python
net-print/pykota-1.25_p2437-r1 dev-lang/python
net-print/pykota-1.25_p2437-r1 dev-lang/python
net-print/pykota-1.26 dev-lang/python
net-print/pykota-1.26 dev-lang/python
net-proxy/http-replicator-3.0-r2 >=dev-lang/python-2.3
net-proxy/http-replicator-3.0-r2 >=dev-lang/python-2.3
net-proxy/ntlmaps-0.9.9-r2 dev-lang/python
net-proxy/ntlmaps-0.9.9-r2 dev-lang/python
net-wireless/wireless-regdb-20090115 dev-lang/python
sci-libs/getdata-0.6.3 dev-lang/python
sci-libs/getdata-0.6.3 dev-lang/python
sci-libs/linux-gpib-3.2.16-r1 dev-lang/python
sci-libs/linux-gpib-3.2.16-r1 dev-lang/python
sci-mathematics/freemat-4.1 dev-lang/python
sci-mathematics/mlpy-3.5.0 >=dev-lang/python-2.6
sci-mathematics/mlpy-3.5.0 >=dev-lang/python-2.6
sci-physics/espresso-3.1.0 dev-lang/python
sys-apps/kudzu-1.2.83-r1 dev-lang/python
sys-apps/pacman-4.0.1 dev-lang/python
sys-apps/pacman-4.0.3 dev-lang/python
sys-apps/paludis-0.66.0 >=dev-lang/python-2.6
sys-apps/paludis-0.66.0 >=dev-lang/python-2.6
sys-apps/paludis-0.68.0 >=dev-lang/python-2.6
sys-apps/paludis-0.68.0 >=dev-lang/python-2.6
sys-apps/paludis-0.70.2 >=dev-lang/python-2.6
sys-apps/paludis-0.70.2 >=dev-lang/python-2.6
sys-apps/paludis-0.72.0 >=dev-lang/python-2.6
sys-apps/paludis-0.72.0 >=dev-lang/python-2.6
sys-apps/paludis-0.72.2 >=dev-lang/python-2.6
sys-apps/paludis-0.72.2 >=dev-lang/python-2.6
sys-apps/paludis-0.74.1 >=dev-lang/python-2.6
sys-apps/paludis-0.74.1 >=dev-lang/python-2.6
sys-apps/paludis-0.76.0 >=dev-lang/python-2.6
sys-apps/paludis-0.76.0 >=dev-lang/python-2.6
sys-apps/pkgcore-0.7.7.8-r2 >=dev-lang/python-2.4
sys-apps/pkgcore-0.7.7.8-r2 >=dev-lang/python-2.5
sys-apps/pkgcore-0.7.7.8-r2 >=dev-lang/python-2.4
sys-apps/pkgcore-0.7.7.8-r2 >=dev-lang/python-2.5
sys-apps/pkgcore-0.8 >=dev-lang/python-2.5
sys-apps/pkgcore-0.8 >=dev-lang/python-2.5
sys-apps/pkgcore-0.8 >=dev-lang/python-2.5
sys-apps/pkgcore-0.8 >=dev-lang/python-2.5
sys-apps/pkgcore-9999 >=dev-lang/python-2.4
sys-apps/pkgcore-9999 >=dev-lang/python-2.5
sys-apps/pkgcore-9999 >=dev-lang/python-2.4
sys-apps/pkgcore-9999 >=dev-lang/python-2.5
sys-apps/portage-2.1.6.7_p1 >=dev-lang/python-2.4
sys-apps/portage-2.1.6.7_p1 >=dev-lang/python-2.4
sys-apps/portage-2.1.10.65 >=dev-lang/python-2.7
sys-apps/portage-2.1.10.65 >=dev-lang/python-2.7
sys-apps/portage-2.1.10.65 >=dev-lang/python-2.7[ssl]
sys-apps/portage-2.1.10.65 >=dev-lang/python-3.3_pre20110902
sys-apps/portage-2.1.11.9 >=dev-lang/python-2.7
sys-apps/portage-2.1.11.9 >=dev-lang/python-2.7
sys-apps/portage-2.1.11.9 >=dev-lang/python-2.7[ssl]
sys-apps/portage-2.1.11.9 >=dev-lang/python-3.3_pre20110902
sys-apps/portage-2.2.0_alpha110 >=dev-lang/python-2.7
sys-apps/portage-2.2.0_alpha110 >=dev-lang/python-2.7
sys-apps/portage-2.2.0_alpha110 >=dev-lang/python-2.7[ssl]
sys-apps/portage-2.2.0_alpha110 >=dev-lang/python-3.3_pre20110902
sys-apps/portage-2.2.0_alpha120 >=dev-lang/python-2.7
sys-apps/portage-2.2.0_alpha120 >=dev-lang/python-2.7
sys-apps/portage-2.2.0_alpha120 >=dev-lang/python-2.7[ssl]
sys-apps/portage-2.2.0_alpha120 >=dev-lang/python-3.3_pre20110902
sys-apps/portage-9999 >=dev-lang/python-2.7
sys-apps/portage-9999 >=dev-lang/python-2.7
sys-apps/portage-9999 >=dev-lang/python-2.7[ssl]
sys-apps/portage-9999 >=dev-lang/python-3.3_pre20110902
sys-apps/razercfg-0.16 dev-lang/python
sys-apps/razercfg-0.16-r1 dev-lang/python
sys-apps/razercfg-0.17 dev-lang/python
sys-apps/razercfg-0.17_p20111028 dev-lang/python
sys-boot/grub-1.99-r2 >=dev-lang/python-2.5.2
sys-boot/grub-2.00_beta6 >=dev-lang/python-2.5.2
sys-boot/grub-2.00 >=dev-lang/python-2.5.2
sys-boot/grub-9999 >=dev-lang/python-2.5.2
sys-cluster/ganglia-3.1.2 >=dev-lang/python-2.3
sys-cluster/ganglia-3.1.2 >=dev-lang/python-2.3
sys-cluster/moosefs-1.6.20-r2 dev-lang/python
sys-cluster/moosefs-1.6.20-r2 dev-lang/python
sys-cluster/moosefs-1.6.25 dev-lang/python
sys-cluster/moosefs-1.6.25 dev-lang/python
sys-devel/distcc-3.0-r4 >=dev-lang/python-2.4
sys-devel/distcc-3.0-r4 >=dev-lang/python-2.4
sys-devel/gdb-7.0.1 dev-lang/python
sys-devel/gdb-7.0.1 dev-lang/python
sys-devel/gdb-7.1 dev-lang/python
sys-devel/gdb-7.1 dev-lang/python
sys-fs/s3ql-1.11.1 >=dev-lang/python-2.7
sys-fs/s3ql-1.11.1 >=dev-lang/python-2.7
sys-libs/libcap-ng-0.6.6 dev-lang/python
sys-libs/libcap-ng-0.6.6 dev-lang/python
sys-libs/libcap-ng-0.7 dev-lang/python
sys-libs/libcap-ng-0.7 dev-lang/python
sys-libs/libsmbios-2.2.19 >=dev-lang/python-2.3
sys-libs/libsmbios-2.2.19 >=dev-lang/python-2.3
sys-libs/openipmi-2.0.11 dev-lang/python
sys-libs/openipmi-2.0.11 dev-lang/python
sys-libs/openipmi-2.0.16 dev-lang/python
sys-libs/openipmi-2.0.16 dev-lang/python
sys-libs/openipmi-2.0.16-r1 dev-lang/python
sys-libs/openipmi-2.0.16-r1 dev-lang/python
sys-libs/openipmi-2.0.18 dev-lang/python
sys-libs/openipmi-2.0.18 dev-lang/python
sys-libs/tevent-0.9.12 >=dev-lang/python-2.4.2
sys-libs/tevent-0.9.12 >=dev-lang/python-2.4.2
sys-libs/tevent-0.9.14-r1 >=dev-lang/python-2.4.2
sys-libs/tevent-0.9.14-r1 >=dev-lang/python-2.4.2
sys-libs/tevent-0.9.15 >=dev-lang/python-2.4.2
sys-libs/tevent-0.9.15 >=dev-lang/python-2.4.2
sys-libs/tevent-0.9.16 >=dev-lang/python-2.4.2
sys-libs/tevent-0.9.16 >=dev-lang/python-2.4.2
www-apps/curator-2.0 >=dev-lang/python-2.2.1
www-apps/curator-2.0 >=dev-lang/python-2.2.1
www-apps/curator-2.1 >=dev-lang/python-2.2.1
www-apps/curator-2.1 >=dev-lang/python-2.2.1
www-apps/pcgi-2.0_alpha5 dev-lang/python
www-servers/servefile-0.4.2 >=dev-lang/python-2.6
www-servers/servefile-0.4.2 >=dev-lang/python-2.7
x11-libs/hippo-canvas-0.3.0 dev-lang/python
x11-libs/hippo-canvas-0.3.0 dev-lang/python
x11-libs/libxcb-1.8.1 dev-lang/python[xml]
x11-libs/xpyb-1.2-r1 >=dev-lang/python-2.5
x11-libs/xpyb-1.2-r1 >=dev-lang/python-2.5
x11-misc/alacarte-0.12.4 >=dev-lang/python-2.4
x11-misc/alacarte-0.12.4 >=dev-lang/python-2.4
x11-misc/xac-0.6_pre4 >=dev-lang/python-2.3
x11-misc/xac-0.6_pre4 >=dev-lang/python-2.3
x11-misc/zim-0.54 >=dev-lang/python-2.6
x11-misc/zim-0.54 >=dev-lang/python-2.6
x11-misc/zim-0.55 >=dev-lang/python-2.6
x11-misc/zim-0.55 >=dev-lang/python-2.6
x11-misc/zim-0.56 >=dev-lang/python-2.6
x11-misc/zim-0.56 >=dev-lang/python-2.6
x11-plugins/purple-plugin_pack-2.5.1-r1 dev-lang/python
x11-plugins/purple-plugin_pack-2.6.2-r1 dev-lang/python

Re: [gentoo-python] Python 3 in Gentoo

[Thomas Sachau]

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

Mike Gilbert schrieb:
> On Tue, Jul 31, 2012 at 11:31 AM, Mike Gilbert <floppym@gentoo.org> wrote:
>> On Mon, Jul 30, 2012 at 1:05 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>>>> So do you know how many ebuilds we'd have to update to get it right?
>>>>
>>>
>>> At the moment, no. If someone could help me write a script to identify
>>> affected packages, that would be great.
>>>
>>> If said script uses the portage api to determine the dependency tree,
>>> we will want to modify python.eclass first to reduce the number of
>>> hits. This could be done in a local copy of the tree.
>>
>> I've created a quick little script and posted it in my devspace. Now I
>> just need to mess with python.eclass.
>>
>> http://dev.gentoo.org/~floppym/python-deps.py
> 
> After modifying python.eclass, distutils.eclass, java-ant-2.eclass,
> and waf-utils.eclass, there are 532 dependencies that would need to be
> modified to make the || dep plan work. I have attached the list for
> reference.
> 
> Does this seem like a viable option? Is anyone going to volunteer to
> take it from here?
> 

If everyone agrees with this route, i suggest a post to the gentoo-dev
mailing list about this planned change and a request for maintainers to
change their dependencies accordingly.
Additionally i suggest to add it also to some written doc, e.g. the
python developer guide.
After giving maintainers some time for that change, we could then open
bugs or do the remaining needed conversions (when the maintainer is
missing or gives his ok).


-- 

Thomas Sachau
Gentoo Linux Developer


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

Re: [gentoo-python] Python 3 in Gentoo

[Jesus Rivero (Neurogeek)]

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

+1
On Aug 8, 2012 5:44 PM, "Thomas Sachau" <tommy@gentoo.org> wrote:

> Mike Gilbert schrieb:
> > On Tue, Jul 31, 2012 at 11:31 AM, Mike Gilbert <floppym@gentoo.org>
> wrote:
> >> On Mon, Jul 30, 2012 at 1:05 PM, Mike Gilbert <floppym@gentoo.org>
> wrote:
> >>>> So do you know how many ebuilds we'd have to update to get it right?
> >>>>
> >>>
> >>> At the moment, no. If someone could help me write a script to identify
> >>> affected packages, that would be great.
> >>>
> >>> If said script uses the portage api to determine the dependency tree,
> >>> we will want to modify python.eclass first to reduce the number of
> >>> hits. This could be done in a local copy of the tree.
> >>
> >> I've created a quick little script and posted it in my devspace. Now I
> >> just need to mess with python.eclass.
> >>
> >> http://dev.gentoo.org/~floppym/python-deps.py
> >
> > After modifying python.eclass, distutils.eclass, java-ant-2.eclass,
> > and waf-utils.eclass, there are 532 dependencies that would need to be
> > modified to make the || dep plan work. I have attached the list for
> > reference.
> >
> > Does this seem like a viable option? Is anyone going to volunteer to
> > take it from here?
> >
>
> If everyone agrees with this route, i suggest a post to the gentoo-dev
> mailing list about this planned change and a request for maintainers to
> change their dependencies accordingly.
> Additionally i suggest to add it also to some written doc, e.g. the
> python developer guide.
> After giving maintainers some time for that change, we could then open
> bugs or do the remaining needed conversions (when the maintainer is
> missing or gives his ok).
>
>
> --
>
> Thomas Sachau
> Gentoo Linux Developer
>
>

[-- Attachment #2: Type: text/html, Size: 2405 bytes --]

Re: [gentoo-python] Python 3 in Gentoo

[Dirkjan Ochtman]

On Wed, Aug 8, 2012 at 11:07 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> Does this seem like a viable option? Is anyone going to volunteer to
> take it from here?

It seems like a monumental pain.

Can we just make it a virtual/python? It seems like that would prevent
us from having to do this more often in the future.

Cheers,

Dirkjan

Re: [gentoo-python] Python 3 in Gentoo

[Richard Yao]

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

On 08/08/2012 05:44 PM, Thomas Sachau wrote:
> Mike Gilbert schrieb:
>> On Tue, Jul 31, 2012 at 11:31 AM, Mike Gilbert <floppym@gentoo.org> wrote:
>>> On Mon, Jul 30, 2012 at 1:05 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>>>>> So do you know how many ebuilds we'd have to update to get it right?
>>>>>
>>>>
>>>> At the moment, no. If someone could help me write a script to identify
>>>> affected packages, that would be great.
>>>>
>>>> If said script uses the portage api to determine the dependency tree,
>>>> we will want to modify python.eclass first to reduce the number of
>>>> hits. This could be done in a local copy of the tree.
>>>
>>> I've created a quick little script and posted it in my devspace. Now I
>>> just need to mess with python.eclass.
>>>
>>> http://dev.gentoo.org/~floppym/python-deps.py
>>
>> After modifying python.eclass, distutils.eclass, java-ant-2.eclass,
>> and waf-utils.eclass, there are 532 dependencies that would need to be
>> modified to make the || dep plan work. I have attached the list for
>> reference.
>>
>> Does this seem like a viable option? Is anyone going to volunteer to
>> take it from here?
>>
> 
> If everyone agrees with this route, i suggest a post to the gentoo-dev
> mailing list about this planned change and a request for maintainers to
> change their dependencies accordingly.
> Additionally i suggest to add it also to some written doc, e.g. the
> python developer guide.
> After giving maintainers some time for that change, we could then open
> bugs or do the remaining needed conversions (when the maintainer is
> missing or gives his ok).
> 
> 

Any changes to package dependencies should be semantically equivalent to
what they are now, so we should only need the Gentoo Python team to sign
off on this. We would still want to make some kind of gentoo-dev
announcement to let people know that this is changing though.


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

Re: [gentoo-python] Python 3 in Gentoo

[Richard Yao]

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

On 08/08/2012 05:07 PM, Mike Gilbert wrote:
> On Tue, Jul 31, 2012 at 11:31 AM, Mike Gilbert <floppym@gentoo.org> wrote:
>> On Mon, Jul 30, 2012 at 1:05 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>>>> So do you know how many ebuilds we'd have to update to get it right?
>>>>
>>>
>>> At the moment, no. If someone could help me write a script to identify
>>> affected packages, that would be great.
>>>
>>> If said script uses the portage api to determine the dependency tree,
>>> we will want to modify python.eclass first to reduce the number of
>>> hits. This could be done in a local copy of the tree.
>>
>> I've created a quick little script and posted it in my devspace. Now I
>> just need to mess with python.eclass.
>>
>> http://dev.gentoo.org/~floppym/python-deps.py
> 
> After modifying python.eclass, distutils.eclass, java-ant-2.eclass,
> and waf-utils.eclass, there are 532 dependencies that would need to be
> modified to make the || dep plan work. I have attached the list for
> reference.
> 
> Does this seem like a viable option? Is anyone going to volunteer to
> take it from here?

I can try to make time to make these changes this weekend if everyone is
fine with that.


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

Re: [gentoo-python] Python 3 in Gentoo

[Dirkjan Ochtman]

On Mon, Aug 13, 2012 at 9:07 PM, Richard Yao <ryao@gentoo.org> wrote:
>> Does this seem like a viable option? Is anyone going to volunteer to
>> take it from here?
>
> I can try to make time to make these changes this weekend if everyone is
> fine with that.

I think we should inform gentoo-dev first.

Cheers,

Dirkjan

Re: [gentoo-python] Python 3 in Gentoo

[Mike Gilbert]

On Mon, Aug 13, 2012 at 3:38 PM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> On Mon, Aug 13, 2012 at 9:07 PM, Richard Yao <ryao@gentoo.org> wrote:
>>> Does this seem like a viable option? Is anyone going to volunteer to
>>> take it from here?
>>
>> I can try to make time to make these changes this weekend if everyone is
>> fine with that.
>
> I think we should inform gentoo-dev first.
>

Just in case someone is waiting for me to take some further actions on
this, please don't wait on me. I really don't have the motivation to
carry this plan any further.

If someone else wants to carry the torch, I am happy to assist.

Re: [gentoo-python] Python 3 in Gentoo

[Thomas Sachau]

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

Mike Gilbert schrieb:
> On Mon, Aug 13, 2012 at 3:38 PM, Dirkjan Ochtman <djc@gentoo.org> wrote:
>> On Mon, Aug 13, 2012 at 9:07 PM, Richard Yao <ryao@gentoo.org> wrote:
>>>> Does this seem like a viable option? Is anyone going to volunteer to
>>>> take it from here?
>>>
>>> I can try to make time to make these changes this weekend if everyone is
>>> fine with that.
>>
>> I think we should inform gentoo-dev first.
>>
> 
> Just in case someone is waiting for me to take some further actions on
> this, please don't wait on me. I really don't have the motivation to
> carry this plan any further.
> 
> If someone else wants to carry the torch, I am happy to assist.
> 
> 

Just to get the right summary:

The plan is now to replace all dependencies in ebuilds, which have
either "dev-lang/python" or something like ">=dev-lang/python-X.Y" to
use "virtual/python" instead?

What about versioned dependencies exluding python versions still in the
main tree like ">=dev-lang/python-2.7"?

-- 

Thomas Sachau
Gentoo Linux Developer


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

Re: [gentoo-python] Python 3 in Gentoo

[Mike Gilbert]

On Sun, Sep 2, 2012 at 8:21 AM, Thomas Sachau <tommy@gentoo.org> wrote:
> Mike Gilbert schrieb:
>> On Mon, Aug 13, 2012 at 3:38 PM, Dirkjan Ochtman <djc@gentoo.org> wrote:
>>> On Mon, Aug 13, 2012 at 9:07 PM, Richard Yao <ryao@gentoo.org> wrote:
>>>>> Does this seem like a viable option? Is anyone going to volunteer to
>>>>> take it from here?
>>>>
>>>> I can try to make time to make these changes this weekend if everyone is
>>>> fine with that.
>>>
>>> I think we should inform gentoo-dev first.
>>>
>>
>> Just in case someone is waiting for me to take some further actions on
>> this, please don't wait on me. I really don't have the motivation to
>> carry this plan any further.
>>
>> If someone else wants to carry the torch, I am happy to assist.
>>
>>
>
> Just to get the right summary:
>
> The plan is now to replace all dependencies in ebuilds, which have
> either "dev-lang/python" or something like ">=dev-lang/python-X.Y" to
> use "virtual/python" instead?
>

That's right.

> What about versioned dependencies exluding python versions still in the
> main tree like ">=dev-lang/python-2.7"?
>

In this case the virtual would not work. Instead, it could be replaced
with this:

|| ( =dev-lang/python-2.7* =dev-lang/python-3* )

Similarly, >=dev-lang/python-2.6 could be replaced with this:

|| ( =dev-lang/python-2.7* =dev-lang/python-2.6* =dev-lang/python-3* )

For >=dev-lang/python-2.5, we can use the virtual since python-2.4 has
been dropped from the tree.

Re: [gentoo-python] Python 3 in Gentoo

[Michał Górny]

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

On Sun, 2 Sep 2012 13:16:38 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> On Sun, Sep 2, 2012 at 8:21 AM, Thomas Sachau <tommy@gentoo.org>
> wrote:
> > Mike Gilbert schrieb:
> >> On Mon, Aug 13, 2012 at 3:38 PM, Dirkjan Ochtman <djc@gentoo.org>
> >> wrote:
> >>> On Mon, Aug 13, 2012 at 9:07 PM, Richard Yao <ryao@gentoo.org>
> >>> wrote:
> >>>>> Does this seem like a viable option? Is anyone going to
> >>>>> volunteer to take it from here?
> >>>>
> >>>> I can try to make time to make these changes this weekend if
> >>>> everyone is fine with that.
> >>>
> >>> I think we should inform gentoo-dev first.
> >>>
> >>
> >> Just in case someone is waiting for me to take some further
> >> actions on this, please don't wait on me. I really don't have the
> >> motivation to carry this plan any further.
> >>
> >> If someone else wants to carry the torch, I am happy to assist.
> >>
> >>
> >
> > Just to get the right summary:
> >
> > The plan is now to replace all dependencies in ebuilds, which have
> > either "dev-lang/python" or something like ">=dev-lang/python-X.Y"
> > to use "virtual/python" instead?
> >
> 
> That's right.
> 
> > What about versioned dependencies exluding python versions still in
> > the main tree like ">=dev-lang/python-2.7"?
> >
> 
> In this case the virtual would not work. Instead, it could be replaced
> with this:
> 
> || ( =dev-lang/python-2.7* =dev-lang/python-3* )
> 
> Similarly, >=dev-lang/python-2.6 could be replaced with this:
> 
> || ( =dev-lang/python-2.7* =dev-lang/python-2.6* =dev-lang/python-3* )

You could go with virtual/python-2.7, -2.6, -2.5 being an appropriate
minimal version.


-- 
Best regards,
Michał Górny

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

Re: [gentoo-python] Python 3 in Gentoo

[Mike Gilbert]

On Sun, Sep 2, 2012 at 1:34 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Sun, 2 Sep 2012 13:16:38 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
>
>> On Sun, Sep 2, 2012 at 8:21 AM, Thomas Sachau <tommy@gentoo.org>
>> wrote:
>> > Mike Gilbert schrieb:
>> >> On Mon, Aug 13, 2012 at 3:38 PM, Dirkjan Ochtman <djc@gentoo.org>
>> >> wrote:
>> >>> On Mon, Aug 13, 2012 at 9:07 PM, Richard Yao <ryao@gentoo.org>
>> >>> wrote:
>> >>>>> Does this seem like a viable option? Is anyone going to
>> >>>>> volunteer to take it from here?
>> >>>>
>> >>>> I can try to make time to make these changes this weekend if
>> >>>> everyone is fine with that.
>> >>>
>> >>> I think we should inform gentoo-dev first.
>> >>>
>> >>
>> >> Just in case someone is waiting for me to take some further
>> >> actions on this, please don't wait on me. I really don't have the
>> >> motivation to carry this plan any further.
>> >>
>> >> If someone else wants to carry the torch, I am happy to assist.
>> >>
>> >>
>> >
>> > Just to get the right summary:
>> >
>> > The plan is now to replace all dependencies in ebuilds, which have
>> > either "dev-lang/python" or something like ">=dev-lang/python-X.Y"
>> > to use "virtual/python" instead?
>> >
>>
>> That's right.
>>
>> > What about versioned dependencies exluding python versions still in
>> > the main tree like ">=dev-lang/python-2.7"?
>> >
>>
>> In this case the virtual would not work. Instead, it could be replaced
>> with this:
>>
>> || ( =dev-lang/python-2.7* =dev-lang/python-3* )
>>
>> Similarly, >=dev-lang/python-2.6 could be replaced with this:
>>
>> || ( =dev-lang/python-2.7* =dev-lang/python-2.6* =dev-lang/python-3* )
>
> You could go with virtual/python-2.7, -2.6, -2.5 being an appropriate
> minimal version.
>

I gave that idea some thought, but I think it would be a somewhat
confusing (it makes my head hurt).

There are actually a few ways I could see a versioned virtual being
implemented; can you articulate exactly what each virtual version
would have in RDEPEND and how it would be used in other ebuilds?

Re: [gentoo-python] Python 3 in Gentoo

[Michał Górny]

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

On Sun, 2 Sep 2012 13:54:13 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> On Sun, Sep 2, 2012 at 1:34 PM, Michał Górny <mgorny@gentoo.org>
> wrote:
> > On Sun, 2 Sep 2012 13:16:38 -0400
> > Mike Gilbert <floppym@gentoo.org> wrote:
> >
> >> On Sun, Sep 2, 2012 at 8:21 AM, Thomas Sachau <tommy@gentoo.org>
> >> wrote:
> >> > Mike Gilbert schrieb:
> >> >> On Mon, Aug 13, 2012 at 3:38 PM, Dirkjan Ochtman
> >> >> <djc@gentoo.org> wrote:
> >> >>> On Mon, Aug 13, 2012 at 9:07 PM, Richard Yao <ryao@gentoo.org>
> >> >>> wrote:
> >> >>>>> Does this seem like a viable option? Is anyone going to
> >> >>>>> volunteer to take it from here?
> >> >>>>
> >> >>>> I can try to make time to make these changes this weekend if
> >> >>>> everyone is fine with that.
> >> >>>
> >> >>> I think we should inform gentoo-dev first.
> >> >>>
> >> >>
> >> >> Just in case someone is waiting for me to take some further
> >> >> actions on this, please don't wait on me. I really don't have
> >> >> the motivation to carry this plan any further.
> >> >>
> >> >> If someone else wants to carry the torch, I am happy to assist.
> >> >>
> >> >>
> >> >
> >> > Just to get the right summary:
> >> >
> >> > The plan is now to replace all dependencies in ebuilds, which
> >> > have either "dev-lang/python" or something like
> >> > ">=dev-lang/python-X.Y" to use "virtual/python" instead?
> >> >
> >>
> >> That's right.
> >>
> >> > What about versioned dependencies exluding python versions still
> >> > in the main tree like ">=dev-lang/python-2.7"?
> >> >
> >>
> >> In this case the virtual would not work. Instead, it could be
> >> replaced with this:
> >>
> >> || ( =dev-lang/python-2.7* =dev-lang/python-3* )
> >>
> >> Similarly, >=dev-lang/python-2.6 could be replaced with this:
> >>
> >> || ( =dev-lang/python-2.7* =dev-lang/python-2.6*
> >> =dev-lang/python-3* )
> >
> > You could go with virtual/python-2.7, -2.6, -2.5 being an
> > appropriate minimal version.
> >
> 
> I gave that idea some thought, but I think it would be a somewhat
> confusing (it makes my head hurt).
> 
> There are actually a few ways I could see a versioned virtual being
> implemented; can you articulate exactly what each virtual version
> would have in RDEPEND and how it would be used in other ebuilds?

Well, one not-so-crazy idea is that we have:

  virtual -2.5, SLOT="2.5+": || ( =python-2* =python-3* )
  virtual -2.6, SLOT="2.6+": || ( python:2.7 python:2.6 =python-3* )
  virtual -2.7, SLOT="2.7+": || ( python:2.7 =python-3* )

  # optioanlly, I think it may be nicer than =python-3* in ebuilds
  virtual -3.1, SLOT="3.1+": =python-3*

It's a bit hacky but with it, you can then do:

  RDEPEND="virtual/python:2.6+"

which is quite self-explanatory.

Alternatively, we could use some recurrency :D.

  virtual -3.1, SLOT="3.1+": =python-3*
  virtual -2.7, SLOT="2.7+": || ( python:2.7 virtual/python:3.1+ )
  virtual -2.6, SLOT="2.6+": || ( virtual/python:2.7+ python:2.6 )
  virtual -2.5, SLOT="2.5+": || ( virtual/python:2.6+ python:2.5 )

-- 
Best regards,
Michał Górny

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

Re: [gentoo-python] Python 3 in Gentoo

[Mike Gilbert]

On Sun, Sep 2, 2012 at 3:02 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Sun, 2 Sep 2012 13:54:13 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
>
>> On Sun, Sep 2, 2012 at 1:34 PM, Michał Górny <mgorny@gentoo.org>
>> wrote:
>> > On Sun, 2 Sep 2012 13:16:38 -0400
>> > Mike Gilbert <floppym@gentoo.org> wrote:
>> >
>> >> On Sun, Sep 2, 2012 at 8:21 AM, Thomas Sachau <tommy@gentoo.org>
>> >> wrote:
>> >> > Mike Gilbert schrieb:
>> >> >> On Mon, Aug 13, 2012 at 3:38 PM, Dirkjan Ochtman
>> >> >> <djc@gentoo.org> wrote:
>> >> >>> On Mon, Aug 13, 2012 at 9:07 PM, Richard Yao <ryao@gentoo.org>
>> >> >>> wrote:
>> >> >>>>> Does this seem like a viable option? Is anyone going to
>> >> >>>>> volunteer to take it from here?
>> >> >>>>
>> >> >>>> I can try to make time to make these changes this weekend if
>> >> >>>> everyone is fine with that.
>> >> >>>
>> >> >>> I think we should inform gentoo-dev first.
>> >> >>>
>> >> >>
>> >> >> Just in case someone is waiting for me to take some further
>> >> >> actions on this, please don't wait on me. I really don't have
>> >> >> the motivation to carry this plan any further.
>> >> >>
>> >> >> If someone else wants to carry the torch, I am happy to assist.
>> >> >>
>> >> >>
>> >> >
>> >> > Just to get the right summary:
>> >> >
>> >> > The plan is now to replace all dependencies in ebuilds, which
>> >> > have either "dev-lang/python" or something like
>> >> > ">=dev-lang/python-X.Y" to use "virtual/python" instead?
>> >> >
>> >>
>> >> That's right.
>> >>
>> >> > What about versioned dependencies exluding python versions still
>> >> > in the main tree like ">=dev-lang/python-2.7"?
>> >> >
>> >>
>> >> In this case the virtual would not work. Instead, it could be
>> >> replaced with this:
>> >>
>> >> || ( =dev-lang/python-2.7* =dev-lang/python-3* )
>> >>
>> >> Similarly, >=dev-lang/python-2.6 could be replaced with this:
>> >>
>> >> || ( =dev-lang/python-2.7* =dev-lang/python-2.6*
>> >> =dev-lang/python-3* )
>> >
>> > You could go with virtual/python-2.7, -2.6, -2.5 being an
>> > appropriate minimal version.
>> >
>>
>> I gave that idea some thought, but I think it would be a somewhat
>> confusing (it makes my head hurt).
>>
>> There are actually a few ways I could see a versioned virtual being
>> implemented; can you articulate exactly what each virtual version
>> would have in RDEPEND and how it would be used in other ebuilds?
>
> Well, one not-so-crazy idea is that we have:
>
>   virtual -2.5, SLOT="2.5+": || ( =python-2* =python-3* )
>   virtual -2.6, SLOT="2.6+": || ( python:2.7 python:2.6 =python-3* )
>   virtual -2.7, SLOT="2.7+": || ( python:2.7 =python-3* )
>
>   # optioanlly, I think it may be nicer than =python-3* in ebuilds
>   virtual -3.1, SLOT="3.1+": =python-3*
>
> It's a bit hacky but with it, you can then do:
>
>   RDEPEND="virtual/python:2.6+"
>
> which is quite self-explanatory.
>

That could work. In this case, we would need to ensure that ebuilds do
not depend on virtual/python without a slot (or version wildcard).

Re: [gentoo-python] Python 3 in Gentoo

[Michał Górny]

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

On Mon, 3 Sep 2012 17:12:18 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> On Sun, Sep 2, 2012 at 3:02 PM, Michał Górny <mgorny@gentoo.org>
> wrote:
> > On Sun, 2 Sep 2012 13:54:13 -0400
> > Mike Gilbert <floppym@gentoo.org> wrote:
> >
> >> On Sun, Sep 2, 2012 at 1:34 PM, Michał Górny <mgorny@gentoo.org>
> >> wrote:
> >> > On Sun, 2 Sep 2012 13:16:38 -0400
> >> > Mike Gilbert <floppym@gentoo.org> wrote:
> >> >
> >> >> On Sun, Sep 2, 2012 at 8:21 AM, Thomas Sachau <tommy@gentoo.org>
> >> >> wrote:
> >> >> > Mike Gilbert schrieb:
> >> >> >> On Mon, Aug 13, 2012 at 3:38 PM, Dirkjan Ochtman
> >> >> >> <djc@gentoo.org> wrote:
> >> >> >>> On Mon, Aug 13, 2012 at 9:07 PM, Richard Yao
> >> >> >>> <ryao@gentoo.org> wrote:
> >> >> >>>>> Does this seem like a viable option? Is anyone going to
> >> >> >>>>> volunteer to take it from here?
> >> >> >>>>
> >> >> >>>> I can try to make time to make these changes this weekend
> >> >> >>>> if everyone is fine with that.
> >> >> >>>
> >> >> >>> I think we should inform gentoo-dev first.
> >> >> >>>
> >> >> >>
> >> >> >> Just in case someone is waiting for me to take some further
> >> >> >> actions on this, please don't wait on me. I really don't have
> >> >> >> the motivation to carry this plan any further.
> >> >> >>
> >> >> >> If someone else wants to carry the torch, I am happy to
> >> >> >> assist.
> >> >> >>
> >> >> >>
> >> >> >
> >> >> > Just to get the right summary:
> >> >> >
> >> >> > The plan is now to replace all dependencies in ebuilds, which
> >> >> > have either "dev-lang/python" or something like
> >> >> > ">=dev-lang/python-X.Y" to use "virtual/python" instead?
> >> >> >
> >> >>
> >> >> That's right.
> >> >>
> >> >> > What about versioned dependencies exluding python versions
> >> >> > still in the main tree like ">=dev-lang/python-2.7"?
> >> >> >
> >> >>
> >> >> In this case the virtual would not work. Instead, it could be
> >> >> replaced with this:
> >> >>
> >> >> || ( =dev-lang/python-2.7* =dev-lang/python-3* )
> >> >>
> >> >> Similarly, >=dev-lang/python-2.6 could be replaced with this:
> >> >>
> >> >> || ( =dev-lang/python-2.7* =dev-lang/python-2.6*
> >> >> =dev-lang/python-3* )
> >> >
> >> > You could go with virtual/python-2.7, -2.6, -2.5 being an
> >> > appropriate minimal version.
> >> >
> >>
> >> I gave that idea some thought, but I think it would be a somewhat
> >> confusing (it makes my head hurt).
> >>
> >> There are actually a few ways I could see a versioned virtual being
> >> implemented; can you articulate exactly what each virtual version
> >> would have in RDEPEND and how it would be used in other ebuilds?
> >
> > Well, one not-so-crazy idea is that we have:
> >
> >   virtual -2.5, SLOT="2.5+": || ( =python-2* =python-3* )
> >   virtual -2.6, SLOT="2.6+": || ( python:2.7 python:2.6 =python-3* )
> >   virtual -2.7, SLOT="2.7+": || ( python:2.7 =python-3* )
> >
> >   # optioanlly, I think it may be nicer than =python-3* in ebuilds
> >   virtual -3.1, SLOT="3.1+": =python-3*
> >
> > It's a bit hacky but with it, you can then do:
> >
> >   RDEPEND="virtual/python:2.6+"
> >
> > which is quite self-explanatory.
> >
> 
> That could work. In this case, we would need to ensure that ebuilds do
> not depend on virtual/python without a slot (or version wildcard).

Well, with proper version ordering you could get the 'virtual/python'
to mean '2.5+'.

/me waits for Ciaran...

-- 
Best regards,
Michał Górny

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