[Distutils] setuptools on jython

[Phillip J. Eby]

At 07:57 PM 1/11/2008 -0800, Philip Jenvey wrote:
>Jython trunk has made a lot of progress on setuptools support. The
>gory details are here:
>
>http://wiki.python.org/jython/SetuptoolsOnJython

By the way, the reason setuptools uses -E for the subprocess is so 
that Python will ignore any environment variables such as PYTHONPATH 
et al.  It's not clear to me whether making -E a no-op for Jython 
will actually make this work correctly.

I also have some concerns about how the $py.class stuff will work 
with distutils in general as well as setuptools in particular, but 
I've tried as much as possible to make setuptools follow the 
distutils rather than do its own thing.  So hopefully most of the 
relevant things will be taken care of by Jython-level distutils patches.


>The final few issues require some changes to setuptools itself:
>
>o usage of os.chmod. most uses are actually wrapped in an os.name ==
>'posix', or except AttributeError checks, but one was missed (Jython
>lacks os.chmod)
>
>o a unit test assumed CPython dict ordering
>
>I've attached a patch against the 0.6 branch for both of these issues.

Thanks!


>Though there's one more issue that'll be more difficult to deal with:
>setuptools uses marshal.load to read variables (via co_names and
>co_consts) from a module's bytecode (pyc/o) without importing it.
>Jython and IronPython don't compile to .pyc, nor do their code
>objects support co_names and co_consts, so this isn't portable.
>
>marshal.load is used in a couple places:
>
>o  setuptools.depends.extract_constant, which is only used in
>setuptools by Require.get_version(). I don't know when this is used
>or what it's used for

setuptools.depends is essentially an experimental pre-egg feature 
that shouldn't be used by anything that's supported or documented at 
the moment.


>o to find un-zip_safe variables/calls when a distribution doesn't
>specify zip_safetyness. Probably the easiest way to deal with this is
>to just fallback to zip_safe=False on these platforms

That's probably reasonable.  An alternative would be to use the 
tokenize module to read the source code, since all it really does is 
look at name tokens and string constants, which can both be 
identified via tokenization without any higher-level parsing.