Ian Bicking: the old part of his blog

Re: Distributing dependencies

I would rather see a separate tarball labeled wsgikit-demo-A.B.C.tar.gz. If I understand WSGIKit correctly, it's a framework, not an application. If you were distributing a fully-independant, batteries-included application for Windows, then including all of the dependencies in a convenience package might be worth it. However, as a framework library, I would be disappointed to see cruft in the tarball. It would simply take up mirror-space and filesystem space for those that wish to create binary packages of your library.

There was recently a discussion on the gnu-prog list about trying to formalize dependency requirements for applications in the form of some XML or RFC-822 document in the top-level directory of the tarball. Most of the ideas where shot down over implementation details, duplication of effort complaints, and unnecessarily making the build process too complicated.

Perhaps if you could leverage PyPI information regarding package versions and locations, you could bootstrap the retrieval and installation of the necessary software for your demo; something you could optionally tie in to setup.py.

Really, what it boils down to is that you need to inform your user of the necessary information rather than trying to hold his/her hand throughout the process.

Comment on Distributing dependencies
by Chad Walstrom


I want a pleasing immediate experience, so informing the user isn't really what I'm looking to do. OTOH, it probably makes sense to package two tarballs. Either way the package includes just one setup.py, and it doesn't install any third-party packages, it would only make a difference when you run the server out of the unpacked directory.

OTOH, Twisted is looking pretty large -- 800K compressed, to include twisted core, twisted.web, and Zope interfaces. Which is disappointing. WSGIUtils and a couple other servers are only a file, so it's easier.

# Ian Bicking