On Sat, 26 May 2012 13:32:30 +0400 Maxim Koltsov wrote: > I want to say that I personally don't want to use python-distutils-ng > in its current state and I know several active python ebuild writers > that are not Gentoo developers and they don't want to use it too. > First of all, how well is this eclass adapted to packages not using > distutils? Old eclass had set of convenient functions > (python_execute_function, python_generate_wrapper_scripts, > python_conver_shebangs). I see some functions like these ones in new > eclass, but can they serve as good replace and is their API public and > stable? We're planning on splitting some basic 'python' eclass out of it. Just someone needs to do that, or I'll when I'll have more time and a good plan. > Then, we think that this ruby-ng style approach with PYTHON_TARGETS is > a bit uncomfortable for end users and developers. This is going to be > pain for all users if eclass gets used widely. Eclass allows developer > not to set PYTHON_COMPAT and populate it with all available values — > well, it's nice. I think we can disable that early if new Python versions are likely to introduce breakages. > But imagine that Python 3.3 arrives. All ebuilds > using new eclass will get new IUSE and therefore will be rebuilt > during emerge --update --newuse world. That's hardly sensible. It's > awful to rebuild packages which might be very 'heavy' just for > nothing. We don't support '--newuse' in Gentoo. People who do that are on their own. We have enough problems to care about in our workflow. > On the other hand, if developers are forced to set PYTHON_COMPAT, this > will result in great delays in getting new python support to Gentoo. > You can say that ruby-ng has the same behavior and nobody complains. > But python is not ruby. Ruby 1.8 to 1.9 transitition was connected > with a lot of incompabilities, so one could not assume that ruby-1.8 > package will work on 1.9. Python 3.2 to 3.3 transitition should be > harmless and almost all packages will require no changes. So some > implicit mechanism of doing this must be implemented. I guess that 3.2->3.3 would include having python3_3 masked for a longer while to test it. -- Best regards, Michał Górny