[Distutils] Deployment with setuptools: a basket-of-eggs approach

[Iwan Vosloo]

Hi Maris,

Ok, I see...

You can thus assume in your environment that the network will always
be there.

I was wondering whether you've ever looked at something like Debian's
apt.  (Mentioned here just to learn from it, not to advocate its use.)
Apt is a wonderful tool for keeping repositories and installing
packages.  It does not solve all problems - and has the drawback that
it only allows one version of something on a system (but you can trick
it by having different package names...).

The hell you're talking about is something that Debian (and, I suppose
other distros) has a lot of experience in managing.  And, for Debian,
apt is the tool. (I don't know the others.)  Of course there are also
a number of conventions and policies that play with to make it work.

I find it odd that you call upon unit testing.  Is the issue not
actually integration testing?  

I think that the only way to deal with the possible complexities of
many packages and dependencies is to impose restictions on when and
how things are released.  For example, all the packages in Debian
release X are tested to work together well (this is integration
testing).  So, in Debian, you don't only have packages, you also have
a set-of-versioned packages (also versioned) which is the release of
the entire distro.  Any new version of a package, or new package that
should work with that distro would need to be tested with all the rest
of the packages in that release of the distro.

I suppose disallowing more than one version of a package on a machine
(like they have done) is one way of simplifying things.  And the
standard workaround for special packages that need more versions, is
to include part of the version in the name.  For example "gcc-3.4"
(version 3.4.2) can be installed alongside "gcc-4.0" (version 4.0.3).

With your scheme, your respository of eggs is also like a single,
shared installation of eggs.  And it may be argued that there is a
difference between putting something in a shared repository (which
means "it is now officially released") versus installing a package on
a machine where it is used.  When you install it, you care about other
localised things too that are not versioned, such as local config or
user data.  And things like apt include ways and means for you to
upgrade user data and deal with config sensibly.

It may be that the simplification of making "install" and "release"
one thing is useful in an environment, I guess.  But in some
environments the simplification may introduce other hellish issues.


(Sorry, I'm just thinking aloud, because I am also faced with such
problems and, by habit, always build things around apt...  So its
interesting to see other thoughts.)

(And, I've no clue as to what platforms apt is available on...)

-i