Issue2143

site-packages inside a jar does not get imported by jython.

workaround:

import site
from org.python.util import jython
jar_location = jython().getClass().getProtectionDomain().getCodeSource().getLocation().getPath()
import site
import os.path
site.addsitedir(os.path.join(jar_location, 'Lib/site-packages'))

Thanks for the workaround, this is very helpful for figuring out how to ensure this logic is always available in standalone mode.

Add site-packages to the sys.path to allow finding site-packages inside a standalone jar

More discussion in the duplicate bug #2149

One idea I have here is that the built-in open function should be able to take a jar URL to the file in question and this can be resolved automagically against a jar that is on sys.path (including via __classpath__)

This change should then work transparently with normal search path resolution.

It should be fairly easy to test this idea out, given that we can directly take the result of getResourceAsStream and pass it to open.

The workaround won't work in limited-permission use scenarios. "all-permissions" is required.

Alex, even for using jar URLs? We will not be directly opening, but provide an alternative reader, via http://docs.oracle.com/javase/7/docs/api/java/net/JarURLConnection.html

I hope this will shed some light to the issue: http://stackoverflow.com/questions/11208681/extract-some-content-from-jar-file-downloaded-with-jws

Alex, that's actually not a bad idea to simply extract the jar to a temporary file directory for these types of operations, vs using the resource API to access. This is very similar to what is done in egg support iirc.

I just worked on standalone support for #2196, and this gave me some fresh insight.

The best approach likely is to provide a new Clamp-specific runner similar to org.python.util.JarRunner. Let's assume a name like org.python.tools.ClampRunner. Clamp currently packs Lib files under /Lib in the jar so they can be used by existing but limited standalone support (see PySystemState#isStandalone for some specifics). Instead ClampRunner will unpack these files to a temporary directory (using the Java 7 support, Files#createTempDirectory), ensuring these are all deleted upon exit (File#deleteOnExit). Then it will call PySystemState#initialize with python.path property set to this unpacked directory.

Because it's a true directory, we will get standard file introspection that caused this bug to be submitted in the frist place.

Note that will also make it feasible to support the package cache using a similar scheme (python.cachedir property setting).

Lastly, this can be done completely outside of the Jython 2.7 dev cycle, but instead in Clamp instead. (Still need to verify that package cache can be constructed without such changes, but it can certainly be used without.)

Hey Jim,

Yeah, was thinking about something similar a while ago. The temp directory
approach may not work in all places, but should work for >80%

Darjus

On Mon, Oct 27, 2014 at 3:55 AM, Jim Baker <report@bugs.jython.org> wrote:

>
> Jim Baker added the comment:
>
> I just worked on standalone support for #2196, and this gave me some fresh
> insight.
>
> The best approach likely is to provide a new Clamp-specific runner similar
> to org.python.util.JarRunner. Let's assume a name like
> org.python.tools.ClampRunner. Clamp currently packs Lib files under /Lib in
> the jar so they can be used by existing but limited standalone support (see
> PySystemState#isStandalone for some specifics). Instead ClampRunner will
> unpack these files to a temporary directory (using the Java 7 support,
> Files#createTempDirectory), ensuring these are all deleted upon exit
> (File#deleteOnExit). Then it will call PySystemState#initialize with
> python.path property set to this unpacked directory.
>
> Because it's a true directory, we will get standard file introspection
> that caused this bug to be submitted in the frist place.
>
> Note that will also make it feasible to support the package cache using a
> similar scheme (python.cachedir property setting).
>
> Lastly, this can be done completely outside of the Jython 2.7 dev cycle,
> but instead in Clamp instead. (Still need to verify that package cache can
> be constructed without such changes, but it can certainly be used without.)
>
> ----------
> nosy: +darjus
>
> _______________________________________
> Jython tracker <report@bugs.jython.org>
> <http://bugs.jython.org/issue2143>
> _______________________________________
>

Moving to low priority now that we have identified a good workaround:

* We will continue to support standalone for to minimize startup time
* But use the ClampRunner approach with unpacking for more general usage

We may want to revisit with Jython 3.x

http://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemprovider.html provides an approach that should work

The workaround mentioned here [site.addsitedir(os.path.join(jar_location, 'Lib/site-packages'))] does not work for me - I assume it related to the fact that jython open() method for opening a file inside a jar does not work.
Currently the only way I can think of to provide a self contained jar is to copy the site-packages directory from the jar into a temp directory and add it to the sys.path, or set it as python.home.
Is there any progress on this issue?