Philipp von Weitershausen wrote at 2007-9-4 00:40 +0200:
>Dieter Maurer wrote:
>> Therefore, it might be helpful, if the known working set would not
>> need to be a singleton (consists of just one element).
>> Assume the following use case:
>>   I use grok to build one of my applications.
>>   I need a another component as well which conflicts with grok.
>>   I override the grok configuration to get the version required
>>   for the other component.
>>   I run the grok testsuite and can then report to the grok community:
>>   "grok" is working with version V of component C as well.
>> This kind of information would be helpful for integrators.
>> It need not necessary be automatically supported by "buildout".
>As far as I understand your use case, i twould already be covered by my 
>original proposal: you always have the option to locally override what's 
>specified in the working set.

I had noticed that.

What is missing is the maintenance of the information that
it has been discovered that "grok" (in our example) is
working not only with the grok-buildout documented known working
set but other working sets as well.

This means: You publish with "grok": it has been reported to work with sets
S1, S2, S3, ...
and not only "We have checked that "grok" works with set "S".

> ...
>But I do agree that it should be possible to rely on other working sets, 
>e.g. Grok application develoeprs relying on the Grok working set which 
>in turn relies on a Zope working set.

That, too, may be an interesting feature.
But, it has not been what I meant.

It is also not trivial to combine known working sets for different

Example: Zope may both work with ZS1 and ZS2 (as far as its test suite
shows) but "grok" may require ZS1 and fail for ZS2.

Zope3-dev mailing list

Reply via email to