#130 Improved "pypi/setuptools" support

[Dieter Maurer]

PyPI has the "full" "pyxb" bundle uploaded (this is good, as the default could well be the "full" package). However, trying to download from "PyPI" (via "easy_install") causes the "pyXB-wssplat-1.1.3.tar.gz" to be downloaded from "sourceforge". The reason is probably the "download url" specification in the metadata pointing to "sourceforge".

"easy_install" fails after the download, complaining that is does not find a "setup script" in the download.

For "PyPI" management, I recommend to split the various bundles
into separate packages with the core as a common dependency and
each "bundle" as a separate package (depending on other bundles or the core). This would make is easy to fetch the correct bundle via "PyPI".

A good PyPI/setuptools integration is especially helpful when "pyXB" is integrated into a larger context with tight "PyPI" integration. I, for example, use it together with Zope/Plone which uses "zc.buildout" to "describe" a configuration. "zc.buildout" makes it very easy to integrate packages with good "PyPI" integration; on the other hand, packages with deficiencies with respect to "PyPI" integration and "setuptools" support can cause quite some headaches.

[Peter A. Bigot]

• status changed from new to accepted

Thanks. Yes, when last I battled easy_install (around the 1.1.0 era), I found it unable to handle PyXB's packaging requirements; not only the bundles, but the presence/placement of the archive files. Consequently, for updates I stopped trying to make it work and pointed it directly to SourceForge.

See http://www.mail-archive.com/pyxb-users@lists.sourceforge.net/msg00028.html.

easy_install seemed much weaker than distutils/setup at that time. I also didn't like its "attitude" about downloading arbitrary material from anywhere to satisfy dependencies without asking whether that was ok.

I agree it's worth some time trying again, though I make no promises.

[Peter A. Bigot]

• milestone changed from PyXB 1.1.4 to PyXB 1.1.5

[Peter A. Bigot]

• status changed from accepted to closed
• resolution set to fixed

Until I hear otherwise, I believe this has been resolved with PyXB 1.1.4 which no longer has multiple downloads.

[Dieter Maurer]

• status changed from closed to reopened
• resolution fixed deleted

Replying to pabigot:

Until I hear otherwise, I believe this has been resolved with PyXB 1.1.4 which no longer has multiple downloads.

"PyXB 1.1.4" now gets installed via "easy_install" in newer Python versions (I tested with Python 2.7). However, it still fails with Python 2.4. The reason is: Python 2.4 does not yet have an "os.path.relpath" and the code for this case is buggy. I will attach a patch in a few minutes.

[Dieter Maurer]

• attachment _pyxb_setup.patch_ added

Patch for Python 2.4 installation problem

[Peter A. Bigot]

• status changed from reopened to closed
• resolution set to fixed

Thanks. I modified that slightly to catch any situation where the substitution does not meet the semantics of os.path.relpath (and to keep using that where it does exist).

commit 3dda421f11077682bf24cfd2cfed4c7dcf52fb73
Author: Peter A. Bigot <pabigot@…>
Date: Fri Aug 24 07:48:18 2012 -0500

trac/130: substitute for missing os.path.relpath