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