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 components. 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. -- Dieter _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
