1 |
On Fri, Oct 26, 2012 at 5:41 PM, Michał Górny <mgorny@g.o> wrote: |
2 |
> On Thu, 25 Oct 2012 17:00:22 -0400 |
3 |
> Mike Gilbert <floppym@g.o> wrote: |
4 |
> |
5 |
>> On Tue, Oct 23, 2012 at 5:58 PM, Michał Górny <mgorny@g.o> wrote: |
6 |
>> > Hello, |
7 |
>> > |
8 |
>> > After starting to deploy python-r1 on packages supporting multiple |
9 |
>> > Python implementations, I believe it is time to start thinking about |
10 |
>> > those packages which don't support that. Firstly, I would like to gain |
11 |
>> > a general feedback/ideas on the possible solutions, without getting too |
12 |
>> > deep into the technical details of it. |
13 |
>> > |
14 |
>> > As far as I can think, we have the following possibilities: |
15 |
>> > |
16 |
>> > |
17 |
>> > 1) Assume that installing stuff for a single Python implementation is |
18 |
>> > deprecated and let the packages rot with the old eclass. |
19 |
>> > |
20 |
>> > It is probably the simplest solution (i.e. not doing anything to |
21 |
>> > address the issue) but truth be told, I doubt this will actually work. |
22 |
>> > People will just keep using the old eclass which doesn't really do much |
23 |
>> > good for those packages... |
24 |
>> > |
25 |
>> > And even if some people will actually start supporting multiple |
26 |
>> > implementations... that may be even worse. Just look at dev-libs/boost |
27 |
>> > to see what I mean. |
28 |
>> > |
29 |
>> > |
30 |
>> > 2) Use a xor-type REQUIRED_USE for those packages. |
31 |
>> > |
32 |
>> > Put the whole set of PYTHON_TARGETS but add a REQUIRED_USE='^^ ( ... )' |
33 |
>> > for them, effectively requesting only a single implementation being |
34 |
>> > enabled. |
35 |
>> > |
36 |
>> > I believe that this is quite a good solution, at least from |
37 |
>> > the dependency point of view. We clearly express which Python |
38 |
>> > implementations are supported by a particular package and which one was |
39 |
>> > enabled. We can express cross-package dependencies cleanly. |
40 |
>> > |
41 |
>> > The problem lies in user-friendliness. Although with the current |
42 |
>> > default (python2_7 only) it wouldn't cause any trouble, whenever user |
43 |
>> > enables more than a single implementation, every single-implementation |
44 |
>> > package will require package.use adjustment. This will become an even |
45 |
>> > more widespread issue when we decide to re-enable Python 3. |
46 |
>> > |
47 |
>> > To be honest, I don't see any good way around that. |
48 |
>> > |
49 |
>> > |
50 |
>> > 3) Use implicit implementation selection (like python.eclass). |
51 |
>> > |
52 |
>> > Well, as some say, this is a very good solution since it's well tested. |
53 |
>> > Its limitations and brokenness are obvious. Just I doubt it is really |
54 |
>> > worth the effort to write something that bad. |
55 |
>> > |
56 |
>> > The main problem here is that the chosen Python implementation is |
57 |
>> > implicit. Binary packages don't express it. Cross-package dependencies |
58 |
>> > don't express it. User changes the implementation, stuff breaks |
59 |
>> > silently and you end up with some kind of python-updater (why a tool |
60 |
>> > to fix breakage is called 'updater'?!). |
61 |
>> > |
62 |
>> > |
63 |
>> > Do you have any more ideas? Opinions? |
64 |
>> > |
65 |
>> |
66 |
>> Like you, I really can't come up with an ideal solution here. |
67 |
>> |
68 |
>> We really have 2 classes of packages here: |
69 |
> |
70 |
> Thanks for pointing that out. |
71 |
> |
72 |
>> 1. Packages that don't care what version of python you use, but |
73 |
>> install files outside of site-packages. |
74 |
> |
75 |
> That sounds a bit like a custom case to me. Not sure if python-r1 |
76 |
> should support those out-of-the-box or just provide a few utility |
77 |
> functions (python-utils-r1?) to help installing them. |
78 |
> |
79 |
>> 2. Packages that build code (like libraries) against a specific |
80 |
>> version of python/libpython. |
81 |
>> |
82 |
>> The implicit implementation selection works fine for #1, but not so well for #2. |
83 |
> |
84 |
> Indeed. The #2 will be probably handled through REQUIRED_USE, if noone |
85 |
> comes up with a better idea. |
86 |
> |
87 |
|
88 |
Yeah, I probably need to remove python3_2 from arch/*/make.defaults |
89 |
before we move forward with that plan. I'm sure that will make a few |
90 |
people feel better anyway. |