Gentoo Archives: gentoo-python

From: "Michał Górny" <mgorny@g.o>
To: Nikolaj Sjujskij <sterkrig@×××××××.com>
Cc: gentoo-python@l.g.o, python@g.o
Subject: Re: [gentoo-python] [PATCH python-r1 2/2] Introduce PYTHON_COMPAT_OVERRIDE to make testing easier.
Date: Thu, 21 Mar 2013 11:54:50
Message-Id: 20130321125523.6c820d63@pomiocik
In Reply to: Re: [gentoo-python] [PATCH python-r1 2/2] Introduce PYTHON_COMPAT_OVERRIDE to make testing easier. by Nikolaj Sjujskij
1 On Thu, 21 Mar 2013 15:30:35 +0400
2 "Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote:
3
4 > Den 2013-03-21 14:27:42 skrev Michał Górny <mgorny@g.o>:
5 >
6 > > On Thu, 21 Mar 2013 10:59:49 +0400
7 > > "Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote:
8 > >
9 > >> Den 2013-03-20 23:03:43 skrev Michał Górny <mgorny@g.o>:
10 > >>
11 > >> > On Wed, 20 Mar 2013 15:10:18 +0400
12 > >> > "Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote:
13 > >> >
14 > >> >> Den 2013-03-18 02:33:50 skrev Michał Górny <mgorny@g.o>:
15 > >> >>
16 > >> >> > The PYTHON_COMPAT_OVERRIDE can be set in the environment to enforce
17 > >> >> > a different set of Python implementations than one being
18 > >> intersection
19 > >> >> > of PYTHON_COMPAT and PYTHON_TARGETS.
20 > >> >> >
21 > >> >> > Due to technical limitations, the variable influences only the list
22 > >> >> > of implementations actually used. USE flags, dependencies and other
23 > >> >> > metadata variables are not modified.
24 > >> >> Push it to tree, please, I'd like to test it :)
25 > >> >
26 > >> > Pushed :).
27 > >> Yup, works fine: https://bugs.gentoo.org/show_bug.cgi?id=462566
28 > >> One minor thing. I have PYTHON_TARGETS="python2_7 python3_3" in
29 > >> make.conf,
30 > >> pylint ebuild has PYTHON_COMPAT=( python2_{5,6,7} python{3_1,3_2} ). I
31 > >> expected `PYTHON_COMPAT_OVERRIDE="python3_3" emerge -1 pylint` to
32 > >> install
33 > >> pylint for both 2.7 and 3.3. Of course, it's "OVERRIDE", not "UPDATE",
34 > >> but
35 > >> still.
36 > >> A minor thing, really, and I won't insist on changing this behaviour.
37 > >> Thanks in any case :)
38 > >
39 > > I've decided to go this way since you can't change the IUSE. Therefore,
40 > > you can't really control the enabled implementations via USE flags. If
41 > > it worked like you suggested, some of the implementations would respect
42 > > USE flags and some other wouldn't -- that would be confusing.
43 > Agreed. But what about something like this:
44 >
45 >
46 > --- /usr/portage/eclass/python-r1.eclass 2013-03-20 23:31:15.000000000
47 > +0400
48 > +++ python-r1.eclass 2013-03-21 15:17:58.000000000 +0400
49 > @@ -604,11 +604,11 @@
50 > ewarn
51 > ewarn "Dependencies won't be satisfied, and PYTHON_TARGETS will be
52 > ignored."
53 > _PYTHON_COMPAT_OVERRIDE_WARNED=1
54 > fi
55 >
56 > - MULTIBUILD_VARIANTS=( ${PYTHON_COMPAT_OVERRIDE} )
57 > + MULTIBUILD_VARIANTS=( ${PYTHON_COMPAT_OVERRIDE} ${PYTHON_TARGETS} )
58 > return
59 > fi
60 >
61 > _python_validate_useflags
62 > _python_check_USE_PYTHON
63 >
64 >
65 > This way eclass would use PYTHON_TARGETS, but equally "disrespect" all the
66 > implementations regarding USE-flags etc, wouldn't it? :)
67 > (Probably we'd have to deal with duplicates in that array, but that's only
68 > an idea).
69
70 Think of PYTHON_COMPAT_OVERRIDE='python2_7 python3_3'. Should 2_7 be
71 enabled if it's both in override and real _COMPAT, and disabled via USE
72 flag?
73
74 --
75 Best regards,
76 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies