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. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
