On 14/05/12 19:42, Nikolaj Sjujskij wrote: > Den 2012-05-14 20:12:51 skrev Krzysztof Pawlik : > >> On 13/05/12 21:57, Dirkjan Ochtman wrote: >>> On Sat, May 12, 2012 at 10:32 PM, Mike Gilbert wrote: >>>> Why not emulate php/ruby and set a default value in the base profile? >>>> See profiles/base/make.defaults. >>>> >>>> I think PYTHON_TARGETS="python2_7 python3_2" would be a reasonable choice. >>> >>> Yeah, I think we should provide a default value, and this default >>> value looks good to me. >> >> Feel free to do so :) I would disagree with adding py3 to default, but it's >> only me. > It would be pretty strange if we had had Py3k as default Python (i.e. in > stage3) and PYTHON_TARGETS for another version altogether. I don't have Py3 installed at all on all my machines. > And how would new eclass behave in such case? Just-out-of-stage3 system would > have only Python 3.2 installed, but PYTHON_TARGETS="python2_7 python3_2". Let's > say user tries to: > # emerge -av pygments > Of course, assuming dev-python/pygments had been ported to new eclass. Would > python-distutils-ng handle this correctly and transparently? Without obscure > errors like "You wants Python 2.7 but haz no Python 2.7"? Without pulling > dev-lang/python:2.7 in? If not, I call this serious usability regression. It seems you have no clue how this eclass works. If you have only py3 installed, and you set PYTHON_TARGETS="python2_7" then dev-lang/python:2.7 will be added to DEPEND and installed. The user asked to install for py2:7 so he will get this done. It's not a usability regression - it's expected behaviour: user wants to build for FOO:X.Y then the eclass adds FOO:X.Y to DEPEND. I fail to see how would you like to "correctly and transparently" (whatever it means to you) do it. If you don't accept as a solution an error message or pulling in py2:7 then there's no other way - you either install missing dependencies or die with an error, no third way. -- Krzysztof Pawlik key id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache...