It's probably worth noting that this is also how people tend to use Store with VW. Nested bundles become un-wieldy so people tend to use a single bundle that acts as a sort of versioned configuration (they have a defined load order). People then tend to use scripts to grab the latest versions of packages in a bundle and that represents the tip development version. To compare with Envy, this is like an open config map with an implicit release (i.e. when you publish a new version of a package, it is implicitly part of the tip version to the bundle). It's still difficult to manage if you have multiple versions of a bundle that are under active and parallel development, but it's not terrible (you have to explicitly update and publish the branch configurations, which generates a lot of useless intermediate versions of the bundle).
Perhaps Monticello could use a couple different types of configurations:
- one where the config specifies exact package versions - one where the config specifies only the package name and the latest version of a given package is always grabbed - one that looks at other meta data associated with the package to determine which to load (such as the latest version with a given tag)...this could be used to better manage concurrent developement streams - one that is completely pluggable with respect to the algorithm used to determine what version of a package is to be loaded (or these could just be new subclasses on an abstract config that people come up with)
Only the first type would be a concrete and unchangeable specification of exact packages and versions. From the other types, you could generate a concreate config (a kind of snapshot of the state of a given config at a point in time). Envy deals with this by having open editions (but you still must explicitly release things in an open edition). I think you could get more mileage by separating these envy concepts (a version vs open edition) such that you can now have configs that are based on some version selection algorithm, and other configs that are an exact specification of package versions.
I agree that pre-requisites are not very useful beyond their documentation value (although, I think in the context of a modular system, pre-requisite specs would be useful...they would serve as a kind of declaration of required bindings that would need to be satisfied before a package could become operational).
- Stephen
Avi Bryant wrote:
On Sun, 28 Nov 2004 14:15:15 +0100, Bert Freudenberg bert@impara.de wrote:
Yes, we're using it now in a project of that size. MC is quite usable now. You might want to make many smaller packages without dependencies, otherwise merging is really slow, and you get a lot of useless versions even though only the prerequisites changed. Instead, we just load the newest version of each package, which works fine in a small team where we can immediately sort out any problems.
Yes, that's how I work as well. It's somewhat telling that the only packages I know of that use the dependency system extensively, OmniBrowser and Chuck, are essentially single-developer projects; for team use, I think my dependency implementation has failed. It's an open question as to how to improve it, and patches are certainly welcome. Speaking of which:
I posted a couple of enhancements for supporting this style of work to the MC list. In particular, packages are highlighted which have a newer version available in the repository. http://mail.wiresong.ca/pipermail/monticello/2004-November/000112.html
Yeah, I'm sorry that I haven't gotten around to integrating these enhancements yet. Real Soon Now ;).
Avi