There have been several bugs, e-mails, IRC discussions about the state of python.eclass and it's several (potentially breaking) changes in the recent past. Now with the (almost) lack of support for EAPI=4 and the python.eclass from Python overlay being exponentially more complex than the current one, I think is time to just break it all again and start over. So, this bug is to keep track of the discussions, suggestions, rants and whatnots of a new python-ng.eclass. To begin with, I would like python-ng.eclass to have some kind of resemblance to ruby-ng.eclass and that documentation would be an integral part of the development process, as this part is what got us to this point. Reproducible: Always
IMO it's not a given that a full rewrite is the best option here; incremental simplification of the current python.eclass might be a better solution. The real problem here is disentangling the complexity that we have now, the advantages that fall out of it (compared to for example the ruby-ng.eclass), and how we might be able to make it manageable. Notes from Arfrever on how to read the eclass code: That code isn't hard to maintain. You might have tried to read things in wrong order. You should firstly read: 1. http://www.gentoo.org/proj/en/Python/developersguide.xml#doc_chap2 2. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html 3. `info bash` 4. "MISCELLANEOUS FUNCTIONS" section of python.eclass 5. "GETTER FUNCTIONS" section of python.eclass 6. "FUNCTIONS FOR PACKAGES SUPPORTING INSTALLATION FOR MULTIPLE PYTHON ABIS" section of python.eclass If you don't understand code from a function, then please ask questions (e.g. in #gentoo-python) and I will answer them. If you think that a function isn't sufficiently documented, then you might report it and I could create a patch for documentation.
For my part, I have gotten used to the eclass in questions, mostly. It provides a lot of power and flexibility. However, I think the major barrier here is documentation and education on its use. A few cannonical examples would be really helpful, as I suspect most people will not wade through the eclass itself. Of course, simplification is always something to shoot for, and I totally support that. It seems to me that a complete re-write is just throwing the baby out with the bath water, so to speak. Regarding how we may proceed from this point, perhaps we could reach a consensus on what elements of the eclass are the most troublesome and work on that. I fear that wholesale changes would require a tremendous amount of work in fixing all the related ebuilds. In any case, inaction is not the best option. Cheers.
the current eclass's are hard to read which make them hard to maintain. either do a whole new one, or lets re-instate arfrever. the overhead of taking over the eclass and all the packages is too high and proxy-committing is redundant work. as everyone here, i'm getting used to the python and distutils eclass. but i still think they require an excessive amount of cruft for a normal dev, especially the non python ones: 1) read way too much doc 2) bloat ebuild with subfunctions and global variables 3) test with as many python abi out in the wild 4) commit and commit again when arfrever tested your ebuild so yes, i would like a python-ng/distutils-ng, ideally it would be minimal and the package manager would do the hard work. python and ruby are not the only languages with multiple versions. meanwhile can still incrementally implement a new python-2 with a few handy fns, defining variable for the python abi, and dealing with .pyc, and some checks. we would only switch to python-ng on a version bump, similarly to how we deal to eapi bumps. the only thing ebuild devs should worry is whether the package works with python 2 and/or 3. especially not jython or pypi or whatever, way too much work, this is only good for crowdsourcing. no one checks all their c packages with gcc, icc, pathcc, clang, pcc, tcc,...
Since we now have python-distutils-ng.eclass, closing this.
