Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 447148 - Removal of python_targets_jython2_5 from -r1 ebuilds
Summary: Removal of python_targets_jython2_5 from -r1 ebuilds
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Python Gentoo Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-13 19:15 UTC by Michał Górny
Modified: 2013-01-05 11:13 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-12-13 19:15:16 UTC
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?
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-12-14 16:07:22 UTC
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?
Comment 2 Dirkjan Ochtman (RETIRED) gentoo-dev 2012-12-14 18:43:49 UTC
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.
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-12-15 11:00:46 UTC
Kicked out from setuptools & argparse too, then.
Comment 4 Martin von Gagern 2013-01-04 17:15:01 UTC
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?
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-01-04 17:23:18 UTC
To be honest, I'd go for modifying the consistency check, and possibly disabling jython in python.eclass some time in the future.
Comment 6 Martin von Gagern 2013-01-04 17:40:06 UTC
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.
Comment 7 Arfrever Frehtes Taifersar Arahesis 2013-01-04 17:43:17 UTC
I think that a news item might be needed. It would tell users of gentoo-x86 where support for Jython is.
Comment 8 Martin von Gagern 2013-01-04 17:49:06 UTC
(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.
Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-01-04 18:03:08 UTC
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.
Comment 10 Dirkjan Ochtman (RETIRED) gentoo-dev 2013-01-04 18:25:42 UTC
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?
Comment 11 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-01-05 09:54:50 UTC
(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.
Comment 12 Martin von Gagern 2013-01-05 10:45:53 UTC
(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.
Comment 13 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-01-05 11:13:24 UTC
(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?