Zip task creates zip file that cannot be imported by Jython (zipimport)

Using Gradle 1.2

Create a zip archive of a directory of python/jython code using the Zip Task

With that zip, add it to python.path, and launch jython. The code will not be loaded in Jython. (alternatively, dynamically load with zipimport.zipimporter(“src.zip”)

Create a python file code.py in src directory

apply plugin: 'java'
  task myZip(type: Zip) {
    archiveName= "src.zip"
      from 'src'
      into '.'
}
import zipimport
  importer = zipimport.zipimporter("src.zip")
  importer.find_module("code")
  # None returned

However, if you zip up the directory with a standard zip progam, or even ant zip task, it works fine. Given this happens only with Gradle zip task, I consider this a probelm in Gradle rather than Jython.

Zip up the src directory with another zip program, and the zipimport would work.

Can you compare the listing (unzip -l src.zip) between the different ways you’re creating the zip?

When I look at the contents of the zip, I see:

Length
    Date
  Time
  Name
---------
---------- -----
 ----
        0
03/11/2015 17:16
 ./
       15
03/11/2015 17:15
 ./code.py
---------
                   -------
       15
                   2 files

If I remove the into(".") in the zip task, it seems to work. The into is unnecessary for Zip tasks because we assume the root of the archive already. The contents look like:

Length
    Date
  Time
  Name
---------
---------- -----
 ----
       15
03/11/2015 17:15
 code.py
---------
                   -------
       15
                   1 file

It seems like we might be creating a directory named ‘./’ and putting things inside it? I’ll look a little more. This is with Gradle 2.3.

OK, and I can make Ant produce the same result with a zipfileset prefix. That makes sense, since we use the same zip libs under the covers.

We should probably warn against this in the documentation. I can’t think of a situation where you’d need to specify ‘into(".")’.

Makes sense, it would mean jars would have the same issue. When the os unzips it, it flattens it out. If the default is into the main directory, no need for into(".") then. Thanks, I will rerun later tonight to confirm

Confirmed, removing into(".") resolves loading issue.