To make ebuilds utilizing python-distutils-ng.eclass usable
"out-of-the-box", the python team would like to add the following to
make.defaults in the base profile.

PYTHON_TARGETS="python2_7"

See also bug 415575 [1].

Any objections?

I would also like to include python3_2, but I do not think this will be
possible due to dev-lang/python:3.2 not being stabilized on several
arches. Perhaps this could be set in arch-specific profiles? Would that
work?

[1] https://bugs.gentoo.org/show_bug.cgi?id=415575

On 05/13/2012 01:27 PM, Mike Gilbert wrote:
> To make ebuilds utilizing python-distutils-ng.eclass usable
> "out-of-the-box", the python team would like to add the following to
> make.defaults in the base profile.
>
> PYTHON_TARGETS="python2_7"
>
> See also bug 415575 [1].
>
> Any objections?
>
> I would also like to include python3_2, but I do not think this will be
> possible due to dev-lang/python:3.2 not being stabilized on several
> arches. Perhaps this could be set in arch-specific profiles? Would that
> work?

The thing is, on "stable" archs, we've got both stable and unstable
users on any given profile. So, eventually it seems like we'll want
something like a use.stable file in order to teak the default
python_targets_* flags for stable users, as suggested here:

https://bugs.gentoo.org/show_bug.cgi?id=415575#c5
--
Thanks,
Zac

On Sun, 2012-05-13 at 16:27 -0400, Mike Gilbert wrote:
> To make ebuilds utilizing python-distutils-ng.eclass usable
> "out-of-the-box", the python team would like to add the following to
> make.defaults in the base profile.
>
> PYTHON_TARGETS="python2_7"
>
> See also bug 415575 [1].

I think this should have been done when the eclass was first committed.
When there is no default setting people will have to set something
themselves and it becomes much harder for the python team to provide a
smooth upgrade path by adding in new preferred targets later on.

> I would also like to include python3_2, but I do not think this will be
> possible due to dev-lang/python:3.2 not being stabilized on several
> arches. Perhaps this could be set in arch-specific profiles? Would that
> work?

Yes, arch-specific profiles would work, we do the same for ruby where
jruby and ree18 are only available on a few arches.

Hans

On Mon, 14 May 2012 07:23:35 +0200
Hans de Graaff <graaff@gentoo.org> wrote:

> On Sun, 2012-05-13 at 16:27 -0400, Mike Gilbert wrote:
> > To make ebuilds utilizing python-distutils-ng.eclass usable
> > "out-of-the-box", the python team would like to add the following to
> > make.defaults in the base profile.
> >
> > PYTHON_TARGETS="python2_7"
> >
> > See also bug 415575 [1].
>
> I think this should have been done when the eclass was first
> committed. When there is no default setting people will have to set
> something themselves and it becomes much harder for the python team
> to provide a smooth upgrade path by adding in new preferred targets
> later on.

Yes, in particular the person who opened my bug has interpreted
the 'any-of' message as 'set to "python2_6 python2_7"'...

--
Best regards,
Michał Górny

On 5/14/2012 12:50 AM, Ben de Groot wrote:
> On 14 May 2012 04:27, Mike Gilbert <floppym@gentoo.org> wrote:
>> To make ebuilds utilizing python-distutils-ng.eclass usable
>> "out-of-the-box", the python team would like to add the following to
>> make.defaults in the base profile.
>>
>> PYTHON_TARGETS="python2_7"
>>
>> See also bug 415575 [1].
>>
>> Any objections?
>
> I think this is a good addition.
>
>> I would also like to include python3_2, but I do not think this will be
>> possible due to dev-lang/python:3.2 not being stabilized on several
>> arches. Perhaps this could be set in arch-specific profiles? Would that
>> work?
>
> I don't see how python:3.2 is useful for most of our users. And I
> especially don't see how having two python versions installed (but
> only one active) is useful for most of our users. So let's make
> sure only one version gets pulled in, unless specifically
> configured by the user.

So long as any installed package depends on dev-lang/python without
specifying a version, the user will end up with python-3 unless they
mask it. There is no easy way out of that situation at this point; I
think it would basically require renaming >=dev-lang/python-3 to
something else.

If we acknowledge that users have both python:3.2 and python:2.7
installed most of the time, I think it makes sense to set the default
value of PYTHON_TARGETS to match that expectation.

El lun, 14-05-2012 a las 11:09 -0400, Mike Gilbert escribió:
> On 5/14/2012 12:50 AM, Ben de Groot wrote:
> > On 14 May 2012 04:27, Mike Gilbert <floppym@gentoo.org> wrote:
> >> To make ebuilds utilizing python-distutils-ng.eclass usable
> >> "out-of-the-box", the python team would like to add the following to
> >> make.defaults in the base profile.
> >>
> >> PYTHON_TARGETS="python2_7"
> >>
> >> See also bug 415575 [1].
> >>
> >> Any objections?
> >
> > I think this is a good addition.
> >
> >> I would also like to include python3_2, but I do not think this will be
> >> possible due to dev-lang/python:3.2 not being stabilized on several
> >> arches. Perhaps this could be set in arch-specific profiles? Would that
> >> work?
> >
> > I don't see how python:3.2 is useful for most of our users. And I
> > especially don't see how having two python versions installed (but
> > only one active) is useful for most of our users. So let's make
> > sure only one version gets pulled in, unless specifically
> > configured by the user.
>
> So long as any installed package depends on dev-lang/python without
> specifying a version, the user will end up with python-3 unless they
> mask it. There is no easy way out of that situation at this point; I
> think it would basically require renaming >=dev-lang/python-3 to
> something else.
>
> If we acknowledge that users have both python:3.2 and python:2.7
> installed most of the time, I think it makes sense to set the default
> value of PYTHON_TARGETS to match that expectation.
>

Would be too difficult to finally fix ebuilds to properly convet
shebangs and so and then, be able to have a proper system even when
python3 is main interpreter?

Personally, I run with it as main interpreter to catch failures, and try
to fix them when possible, maybe all devs should do the same to fix
packages still not working at all.

On 5/14/2012 11:17 AM, Pacho Ramos wrote:
> Would be too difficult to finally fix ebuilds to properly convet
> shebangs and so and then, be able to have a proper system even when
> python3 is main interpreter?

Yeah, python_convert_shebangs is an easy fix for most cases.

> Personally, I run with it as main interpreter to catch failures, and try
> to fix them when possible, maybe all devs should do the same to fix
> packages still not working at all.

Thanks for that, the help is appreciated.

On 5/13/2012 4:27 PM, Mike Gilbert wrote:
> To make ebuilds utilizing python-distutils-ng.eclass usable
> "out-of-the-box", the python team would like to add the following to
> make.defaults in the base profile.
>
> PYTHON_TARGETS="python2_7"
>
> See also bug 415575 [1].
>
> Any objections?
>

Seeing no objections to this part, I plan to add
PYTHON_TARGETS="python2_7" to the base profile in the next day or so.

On Mon, 14 May 2012 13:52:49 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> On 5/13/2012 4:27 PM, Mike Gilbert wrote:
> > To make ebuilds utilizing python-distutils-ng.eclass usable
> > "out-of-the-box", the python team would like to add the following to
> > make.defaults in the base profile.
> >
> > PYTHON_TARGETS="python2_7"
> >
> > See also bug 415575 [1].
> >
> > Any objections?
> >
>
> Seeing no objections to this part, I plan to add
> PYTHON_TARGETS="python2_7" to the base profile in the next day or so.

That's a slightly better kind of madness than adding python3 to any
arch that happens to have python3 stable. Good luck out there.


jer

On 16:27 Sun 13 May , Mike Gilbert wrote:
> To make ebuilds utilizing python-distutils-ng.eclass usable

I didn't read any farther because I couldn't stop laughing. What will
the next version of this eclass be called, -ng-ng? -really-ng? =)

--
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>