Differences between revisions 21 and 23 (spanning 2 versions)
Revision 21 as of 2007-12-29 01:40:13
Size: 2598
Editor: PhilipJenvey
Comment: update likely order in which i'll attack these, lstat updates
Revision 23 as of 2008-01-10 05:11:52
Size: 4037
Editor: PhilipJenvey
Comment: we have lstat and fixed command line -E. update marshal info
Deletions are marked like this. Additions are marked like this.
Line 31: Line 31:
We don't have:
  
 * imp.acquire/release_lock (and the accompanying lock_held which we don't actually need). Exposes the import machinery's lock via the imp module '''''Added in r3894'''''
Line 35: Line 35:
  -E codec : Use a different codec the reading from the console.
   
 * imp.acquire/release_lock
  This is just a simple lock, but probably needs to be used by internal imp operations. I'm not sure
  -E codec : Use a different codec the reading from the console. '''''-E codec renamed to -C codec in r4013. -E is now a noop (but valid) command line arg'''''

 * os.lstat. setuptools cut and pasted shutil's rmtree from CPython 2.4, which uses lstat to check for a directory vs a symlink to a directory. We now support an os.stat that fills in st_mode's directory bit, but can we support lstat? (We definitely can with JNA)? Can setuptools avoid lstat completely (requiring a patch)? I don't think Java can safely determine a sym link yet. Java 1.7's JSR 203 (nio part 2) should address this as well as chmod, but we obviously need a solution for Java 1.5 '''''Turned out we can implement a simple lstat in pure Java, added in r4014'''''

We don't have:
Line 41: Line 42:

 * setuptools' use of marshal: setuptools uses marshal.load in two places -- to get a code object from a .pyc file, so it can scan the code object's co_names and co_consts (basically to read a module's variables without importing it).

  the two places this is used:

  1. when a package doesn't mark itself as zip_safe, setuptools will scan it for special variable names (like '__file__') to determine zip_safetyness.
Line 42: Line 49:
 * os.lstat. setuptools cut and pasted shutil's rmtree from CPython 2.3, which uses lstat to check for a directory vs a symlink to a directory. We now support an os.stat that fills in st_mode's directory bit, but can we support lstat? (We definitely can with JNA)? Can setuptools avoid lstat completely (requiring a patch)? I don't think Java can safely determine a sym link yet. Java 1.7's JSR 203 (nio part 2) should address this as well as chmod, but we obviously need a solution for Java 1.5

 * working marshal? setuptools uses marshal.load in a couple places, which either needs to be avoided or possibly some work done to Jython's marshal module
  2. setuptools.depend.get_module_constant: a generic way to grab the value of a module variable. currently only used by Require.get_version
 
 
In Jython, in some cases the zip_safe check will avoid the marshal.load code path because there won't be any .pyc or .pyos in the package (because jython's distutils compiles .py to $py.class instead). Though there may be cases where Jython installs a .egg that already includes .pycs (they aren't pruned).
 
Unfortunately setuptools is defaulting zip_safe to True unless proved otherwise (and it won't be proved otherwise no .pycs exist). So even if marshal.load is avoided in some cases, those cases can be incorrectly marked as being zip_safe when they are not.
 
We'll probably need setuptools patched to just assume zip_safe=False under jython when a package doesn't define it, and to avoid marshal.load completely when scanning for zip_safety under Jython. I'm not sure how to workaround issue #2

Setuptools requirements:

  • PEP 302 style zipimport module Added in r3463

  • number of misc. Jython bug fixes most already committed

  • file descriptor support for tempfile.mkstemp, os.open and tarfile Added in r3711

  • tempfile.mkstemp Added in r3712

  • os.chdir (also needed for distutils) Added in r3844

  • tarfile module Added in r3850

  • a valid sys.executable. required by setuptools and distutils for spawning subprocesses. Added in r3867, enabled via -Dpython.executable (see http://article.gmane.org/gmane.comp.lang.jython.devel/4068 )

  • a site-packages dir (jython needs to include it on sys.path by default). required by setuptools and distutils Added in r3886

  • distutils: requires [http://hg.underboss.org/jython-pjenvey/rev/1026fe32c01c a number of small patches]:

    • a valid sys.executable Added in r3867

    • getpass module Added in r3876

    • distutils metadata for the os.name == 'java' (like path names, default bdist type, etc)
    • a jython spawn-like function: "error: don't know how to spawn programs on platform 'java'". os.system works as a replacement
    • compile .py files to $py.class instead of .pyc distutils and these last 3 modifications were added in r3888

  • imp.acquire/release_lock (and the accompanying lock_held which we don't actually need). Exposes the import machinery's lock via the imp module Added in r3894

  • setuptools runs a test to ensure .pth files work by running "sys.executable -E -c pass". -E is ignore environment on CPython, but is different on Jython (takes an argument):
    • -E codec : Use a different codec the reading from the console. -E codec renamed to -C codec in r4013. -E is now a noop (but valid) command line arg

  • os.lstat. setuptools cut and pasted shutil's rmtree from CPython 2.4, which uses lstat to check for a directory vs a symlink to a directory. We now support an os.stat that fills in st_mode's directory bit, but can we support lstat? (We definitely can with JNA)? Can setuptools avoid lstat completely (requiring a patch)? I don't think Java can safely determine a sym link yet. Java 1.7's JSR 203 (nio part 2) should address this as well as chmod, but we obviously need a solution for Java 1.5 Turned out we can implement a simple lstat in pure Java, added in r4014

We don't have:

  • os.chmod. This can be implemented with JNA. We can still support setuptools on deployments lacking JNA if we submit a patch back to setuptools to only use chmod if it exists
  • setuptools' use of marshal: setuptools uses marshal.load in two places -- to get a code object from a .pyc file, so it can scan the code object's co_names and co_consts (basically to read a module's variables without importing it).
    • the two places this is used:
    • when a package doesn't mark itself as zip_safe, setuptools will scan it for special variable names (like 'file') to determine zip_safetyness.

    • setuptools.depend.get_module_constant: a generic way to grab the value of a module variable. currently only used by Require.get_version

In Jython, in some cases the zip_safe check will avoid the marshal.load code path because there won't be any .pyc or .pyos in the package (because jython's distutils compiles .py to $py.class instead). Though there may be cases where Jython installs a .egg that already includes .pycs (they aren't pruned).

Unfortunately setuptools is defaulting zip_safe to True unless proved otherwise (and it won't be proved otherwise no .pycs exist). So even if marshal.load is avoided in some cases, those cases can be incorrectly marked as being zip_safe when they are not.

We'll probably need setuptools patched to just assume zip_safe=False under jython when a package doesn't define it, and to avoid marshal.load completely when scanning for zip_safety under Jython. I'm not sure how to workaround issue #2

SetuptoolsOnJython (last edited 2010-01-02 16:58:16 by AndrewKuchling)