I'm thinking of removing jython2_5 from PYTHON_COMPAT in the few ebuilds where it appears. Jython 2.5 has more issues than any other Python implementation, is no longer maintained nor really useful. Also, it is terribly slow. I think a few packages require jython:2.5 itself but I doubt there's real-world usage for building random packages with jython. The '-r1' packages which currently have jython enabled are: 1) argparse [I'd leave this one], 2) coverage [revdeps don't support jython], 3) setuptools [jython fails tests], 4) pyserial [tests are skipped on my system due to lack of serial port support in icedtea]. Do you have any objections?
I've removed the support from coverage and pyserial. That leaves setuptools & argparse the only packages supporting jython2.5 in the new eclass. Shall I keep them for some time or even disable jython in the virtual/python-argparse?
I'm fine with kicking out Jython 2.5 entirely, though it would be nice to revive it once 2.7 gets released. Although I really don't care that much, TBH.
Kicked out from setuptools & argparse too, then.
Removing jython support from setuptools breaks a lot of old python packages. If I enable jython in PYTHON_TARGETS (mostly out of curiosity, and as the docs tell me it should be possible to do so), then I see a warning advising me to enable it in USE_PYTHON as well. And as many non-r1 packages don't explicitely forbid building against jython, many of these currently fail to build due to jython2.5 setup.py build -b build-2.5-jython Traceback (most recent call last): File "setup.py", line ??, in <module> from setuptools import setup, find_packages ImportError: No module named setuptools So please make things consistent again, both at the eclass level and the documentation. One possible way: * Advise people against including jython in their USE_PYTHON variable * Omit jython in the check for consistency between PYTHON_TARGETS and USE_PYTHON * Only enable jython for -r1 packages for which all deps are -r1 as well, so they explicitely claim supporting jython. I.e. opt-in instead of opt-out. Other aproaches are possible as well, e.g. drop jython from PYTHON_TARGETS altogether, or find a way to make jython work for the majority of packages, but both of these appear less desirable to me. Do you want to reopen this bug here till things are consistent again, or would you prefer a follow-up bug report to deal with this?
To be honest, I'd go for modifying the consistency check, and possibly disabling jython in python.eclass some time in the future.
On IRC, Arfrever stated: "Jython is now supported only in Progress Overlay". If that is general consensus, then removing all references to Jython from all eclasses of the main portage tree, including the -r1 ones, seems like a reasonable course of action. And the docs (http://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml in particular) should be adjusted as well, of course.
I think that a news item might be needed. It would tell users of gentoo-x86 where support for Jython is.
(In reply to comment #7) > I think that a news item might be needed. It would tell users of gentoo-x86 > where support for Jython is. If the code which checks PYTHON_TARGETS and USE_PYTHON for valid values is adjusted in such a way that it considers jython invalid, then that code might include useful informations about the Progress overlay in an error message. That way, those who *do* currently use Jython will notice the change, and those who don't won't be bothered by a news item which is of no concern to them.
If someone actually uses and needs Jython for anything, we'd be happy to help and add support for necessary packages. However, the idea of enabling it for random packages while they almost always fail tests with jython is not really good, I guess. Directing people at Progress overlay is out of Gentoo's business. So far, Progress overlay is not and never was supported by Gentoo. I believe it gives us more trouble than help. Therefore, I would appreciate if you could stop spamming about your overlay every time somebody asks for something.
Yeah, we're not going to refer users to the Progress overlay. Michał, can you start a thread on gentoo-python about what kind of breakage we're expecting for people who currently have jython enabled?
(In reply to comment #4) > If I enable jython in PYTHON_TARGETS (mostly out of curiosity, and as the > docs tell me it should be possible to do so), then I see a warning advising > me to enable it in USE_PYTHON as well. Wait, how did you exactly get this warning? It shouldn't be happening with -r1 packages not supporting jython... which would mean that you enabled jython2_5 in some package yourself ignoring the policy docs ;P.
(In reply to comment #11) > Wait, how did you exactly get this warning? It shouldn't be happening with > -r1 packages not supporting jython... which would mean that you enabled > jython2_5 in some package yourself ignoring the policy docs ;P. Sorry, seems this was a false alarm. My last warning in that direction was for pypy, and only the docs advised me to keep the variables totally in sync, including jython. It might be that I did read a warning about jython before that, at a time when there were -r1 packages still claiming support for jython, but if so I can't find it just now, and in any case it should be solved by now. But you are right, I ignored the policy docs, hadn't even read them. The title meant nothing to me, but as I considered myself a user, I thought the user's guide should be the right document to read. Perhaps you should add a link to the policy dot to the user's guide, explaining that this might serve as a guideline as to what targets should be exnabled, and what support one might expect for them.
(In reply to comment #12) > But you are right, I ignored the policy docs, hadn't even read them. The > title meant nothing to me, but as I considered myself a user, I thought the > user's guide should be the right document to read. Perhaps you should add a > link to the policy dot to the user's guide, explaining that this might serve > as a guideline as to what targets should be exnabled, and what support one > might expect for them. Well, I referred to the policy docs because I thought you were modifying ebuilds. If it's not, then no worry. I wonder how to make that clear in docs. Maybe we should move the implementation support state to user doc from policy one?