- Hi,
- This can be another troll-thread or layman-thread, but still I think this question must be raised once more.
- I want to say that I personally don't want to use python-distutils-ng in it's 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?
- 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. 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.
- 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 will be harmless and almost all packages will require no changes. So some implicit mechanizm of doing this must be implemented.
- So, new eclass has serious problems in its current state, old is bad too, not to say here why, and we have no solution yet :)
- But still discussion is needed, or we will end up accepting silently bad decisions. Please speak up everyone who agrees with me and/or has any suggestions.