I updated the jython ebuild to make it deal with 2.2a1, which brings significant improvements in the python side (generators mainly). Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 68645 [details] new ebuild New ebuild, tested locally
Created attachment 68646 [details] new files/jython, using a per-user $HOME/cachedir, including settings for libreadline-java jython has lots of problems if it can't write the cachedir. The old ebuild was using a shared cachedir at /usr/share/jython/cachedir, which brings security problems and issues if root writes a cache and then other user can't update it. I keep python.home at /usr/share/jython, but set cachedir to $HOME/cachedir using this command line tool.
Some quick feedback: 1.you need to depend on the slot of servletapi you are using (=dev-java/servletapi-2.4*) 2.just use dobin when you don't need to rename the binary 3.it seems that S="${WORKDIR}" in your ebuild so you should set that and then you don't need to always use cd ${WORKDIR} The newbin problem seems to be also in the old ebuild but useful to be aware of it. I have added python@gentoo.org to CC so that they can provide feedback on howto implement the python tricks in the best way.
>1.you need to depend on the slot of servletapi you are using >(=dev-java/servletapi-2.4*) I don't actually need an specific version, but there seems to be no way to get the jar of unspecified servletapi version. Or there is? In any case, this is a flag to build support for using jython to serve python files as servlets, so not so mainstream. >2.just use dobin when you don't need to rename the binary Done here, I also discovered a couple of minor glitches which I have fixed locally too. Unless there are more comments/problems, I'll attach the changed files tomorrow. >3.it seems that S="${WORKDIR}" in your ebuild so you should set that and then >you don't need to always use cd ${WORKDIR} Done too. Thanks for the advice, I'm an ebuild novice.
(In reply to comment #4) > > I don't actually need an specific version, but there seems to be no way > to get the jar of unspecified servletapi version. Or there is? > In any case, this is a flag to build support for using jython to serve > python files as servlets, so not so mainstream. > But remember that your package has to build with the deps you have. Any version of servletapi is ok by your DEPEND but for your ebuild to work you need one from the 2.4 slot. > Done too. Thanks for the advice, I'm an ebuild novice. No problem. We apreciate every level of work and are here to help you improve your skills.
Comment on attachment 68646 [details] new files/jython, using a per-user $HOME/cachedir, including settings for libreadline-java #!/bin/sh ############################################################################### # # This file generated by Jython installer # Created on XXX by root # # Note, java.library.path is needed for readline use only. # And probably /usr/lib should be added at the java-config level after # implementation native libs. `java-config --java` -Dpython.home="/usr/share/jython" -Dpython.cachedir=$HOME/cachedir -Djava.library.path=/usr/lib -classpath "`java-config --classpath=jython,libreadline-java 2>/dev/null`:$CLASSPATH" "org.python.util.jython" "$@"
Created attachment 68742 [details] new version of proposed ebuild this takes into account the received suggestions, AFAICT
Created attachment 68796 [details] includes java.library.path to make readline happy this one makes optional readline really work.
This is still alpha and is a binary package. As per the Gentoo Java policy, we are not adding new binary packages. Please wait until the actual release for Jython 2.2 is made (it seems that 2.1 is still the newest version from their homepage).
*** Bug 127192 has been marked as a duplicate of this bug. ***
>This is still alpha and is a binary package. As per the Gentoo Java policy, we >are not adding new binary packages. Please wait until the actual release for 2.2a1 is not alpha in the typical sense, it is in the plans for python. If you ask: $ python -c "import __future__; print __future__.generators.optional" (2, 2, 0, 'alpha', 1) you find 2.2a1 is the first version implementing generators, which is (has been for the last two years) extremely useful. OTOH, even if the package that is downloaded includes a (architectureless) binary, the ebuild compiles it from sources, so the second claim is fake too. >Jython 2.2 is made (it seems that 2.1 is still the newest version from their >homepage). Keep on waiting (one year and a half and one beta later). I'm attaching a changed and cleaner ebuild for 2.2b1
Created attachment 114304 [details] ebuild for 2.2beta1 Tested to generate a working /usr/bin/jython both with and without libreadline-java. Not too clean :) Downloads CPython Lib from required version (2.2.3 currently) and it no longers depends on python-2.2
I have taken the existing 2.1 ebuild as well as Santiago's ebuild/input and combined them to produce https://overlays.gentoo.org/svn/proj/java/java-experimental/dev-java/jython/jython-2.2_beta1.ebuild So far it seems to work using simple programming examples ( I know nothing about python ) It would be nice if the more experienced python programmers within the gentoo-java team, as well as any community members, attempt to stretch this ebuilds legs. To see whether the user cachedir is working, etc,etc The ebuild needs a bit of a clean up, I just noticed that is inherits base without any need. These im less concerned about until it is closer to being ready of the java-overlay (and eventually the tree). I also pulled the code from jythons svn repo. I haven't included the steps to reproduce in the ebuild but it was a simple export from the 2.2beta tag. Thank you Santiago for your hard work.
I have been taking a look to the ebuild. You can't build a python2.2 using the libraries of a python 2.4, so: echo "python.home=/usr/lib/python2.4/" >> ant.properties is basically broken unless you can get /usr/lib/python2.2 this is why I opted by adding python 2.2.3 tarball to the ebuild, instead of depending on a masked python 2.2 To get an idea of the "breakage", $ jython /usr/share/jython/Lib/test/testall.py (it fails unless the user running it has permissions on /usr/share/jython, it fails unless test_jarray is commented) I get it ok after a lot of messages, in my ebuild (commenting test_jarray, seems to be missing). Other than this, your proposal looks good, but the launcher will not launch if "readline" is used, as it needs to -Djava.library.path and add it to the classpath. Look at mine, I went through hoops to ensure it works with and without readline.
Created attachment 115531 [details] mylar/context/zip Push for it in gentoo
Comment on attachment 115531 [details] mylar/context/zip oops, forget the spam
A few days ago (Jun 23) 2.2-rc1 was announced. It looks fairly mature, after extensive testing of alphas, beta1 and beta2. As you might *not* know, python has official alpha and beta releases and, for instance, 2.2-alpha1 is the first release with mandatory generators support. This is to say that alpha and beta in python is not like in other packages. I'll upload an updated ebuild in case you like it.
Created attachment 123403 [details] tentative ebuild for 2.2-rc1 Note that the ebuild requires changes when bumping, to the download file and the associated python sources. Works for me (TM)
Created attachment 124748 [details] Ebuild for jython 2.2-rc2 jython 2.2-rc2 released, about one week for 2.2 Ebuild attached, seems to work well. Result of tests (once jarray one was commented, it is missing from the distribution): (... long output ) All old-style tests completed successfully! Executing unittest tests ................. ---------------------------------------------------------------------- Ran 17 tests in 0.971s OK
Took a look at bumping to 2.2 final. Unfortunately freemarker does not build with it so will need to look at patching it. Would like to avoid slotting jython if possible.
Upstream lists 2.2.1 as recommended, I have tested my ebuild and it works, yet gentoo has a version more than 2 years old of the package. Can't really know what is the reason that makes it happen, but I guess it is the framemarker stuff: if framemarker is not correctly supported, it is framemarker that should be punished, and not jython. What does QA say about those cases? I guess having generators in python plus 2 years delay in the ebuild is enough reason to bump jython and put blocks and/or bugs in any ebuild broken by that. Isn't it?
Why is this not committed to portage yet? The jython ebuild currently available is *too old*. This (or the newest version) should be included in portage, either as ~x86 or masked for testing. Thanks, Nilton
Added jython to tree, had been sitting in java-experimental for ages and after a little bit of cleanup. I have deemed it suitable for ~arch. Note I have had to restrict="test" as they are useless. I will be interested to see how stable the package actually is. Cachedir is now generated in $HOME.
