1 |
Den 2013-03-13 23:49:33 skrev Michał Górny <mgorny@g.o>: |
2 |
|
3 |
> On Wed, 13 Mar 2013 13:20:19 +0400 |
4 |
> "Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote: |
5 |
> |
6 |
>> Den 2012-12-13 14:44:41 skrev Michał Górny <mgorny@g.o>: |
7 |
>> |
8 |
>>> PYTHON_COMPAT_OVERRIDE is an environment variable which overrides |
9 |
>>> the current value of PYTHON_COMPAT. |
10 |
>>> |
11 |
>>> Useful for testing packages with new Python implementations quickly |
12 |
>>> without modifying the ebuild. Outputs a lot of noisy warnings to make |
13 |
>>> sure people notice how hacky it is. |
14 |
>>> |
15 |
>>> Example use: |
16 |
>>> |
17 |
>>> $ PYTHON_COMPAT_OVERRIDE=python3_3 emerge -1v dev-python/nose |
18 |
>> |
19 |
>> Has it been pushed to tree? |
20 |
>> |
21 |
>> % grep -r PYTHON_COMPAT_OVERRIDE /usr/portage/eclass/* |
22 |
>> <nothing> |
23 |
>> |
24 |
>> And I don't see anything related in ML archives. Have I missed |
25 |
>> something? |
26 |
> |
27 |
> It couldn't work properly, so I withdrawn it. The major problem is that |
28 |
> metadata becomes affected by environmental variables. |
29 |
> |
30 |
> Sadly, portage can't handle that nicely. Usually, it just results in |
31 |
> portage 'sticking' with one particular set of USE flags on the package |
32 |
> and trying to use the other one at the same time. In other words, a lot |
33 |
> of random behavior and QA warnings. |
34 |
> |
35 |
> Probably, the nearest thing that could work is PYTHON_COMPAT_OVERRIDE |
36 |
> which doesn't use the USE flags but instead forces all impls listed. |
37 |
I see... Well, that's unfortunate, I hoped to test pylint with it, |
38 |
hacking ebuild just for changing PYTHON_COMPAT isn't much fun. |