hi steven

this is really interesting.  Thanks for sharing that with us.

> 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.

Do you know one bundle on store that contains such a kind of scripts ;))

>  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).

I agree with you. It seems that pre-requisite specs are really  
important to understand how several
packages work together and for example should be managed all together  
(removed for example from a config map) but on the other hand you do  
not want to have a propagation of changing versions.
So what is your practices/advices with that?

Stef

>
> - Stephen
>
> Avi Bryant wrote:
>
>> On Sun, 28 Nov 2004 14:15:15 +0100, Bert Freudenberg <bert at 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
>>
>>
>
>