code packaging

Paul Rubin http
Fri Jul 20 12:13:19 CEST 2007


I've been through this kind of thing a few times in the past and
received excellent advice here on clpy about how to deal with specific
technical aspects (e.g. how to use setuptools, InnoSetup, etc).  

I'm now wondering where this type of thing is best addressed in more
general terms.  What I usually see happening, in projects I've worked
on and in others, is that developers get the code working on their own
computers, using source control tools and (if we're lucky) tests
developed in parallel with the code, but without much attention to
final packaging until the very end when the code is about to be
shipped.

Is this appropriate?  Inappropriate?  Do your projects start using
serious packaging and distribution tools very early in development,
before the code is anywhere near usable?  Should they?

I'm involved in something that I wish was that way, mainly because I
really don't have any way to put a complete installation on my own
computers; I have to develop my subsystem more or less independently
of the overall app, then toss stuff over the wall to the more central
application guys for integration, which gets slow sometimes because
we're distributed all over.  This is a fairly complex server app that
depends on a lot of external packages and programs running across
multiple machines, so I could see the packaging problem being messy.
It would cause a significant interruption in development to try to
package things so that the non-central developers could install and
hack it without a lot of assistance.  But I think it would be
worthwhile given how much easier it would become to test changes.  We
do plan to bundle up and release the code sometime (maybe as a Debian
package) but for now that's deferred until the code is more complete
and stable.

I'm wondering how other projects go about this.



More information about the Python-list mailing list