#130 Improved "pypi/setuptools" support

PyXB 1.1.5
closed
fixed
Binding model
minor
PyXB 1.1.3
enhancement
2012-08-25
2012-03-12
No

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.

1 Attachments

Discussion

  • Peter A. Bigot

    Peter A. Bigot - 2012-03-12
    • 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

    Peter A. Bigot - 2012-06-13
    • milestone changed from PyXB 1.1.4 to PyXB 1.1.5
     
  • Peter A. Bigot

    Peter A. Bigot - 2012-06-29
    • 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

    Dieter Maurer - 2012-07-01
    • 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

    Dieter Maurer - 2012-07-01

    Patch for Python 2.4 installation problem

     
  • Peter A. Bigot

    Peter A. Bigot - 2012-08-25
    • 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

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks