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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
