[Zope3-dev] Re: Known working sets II [was: Eggification redux]

Jim Fulton jim at zope.com
Tue Sep 25 10:50:53 EDT 2007


On Sep 25, 2007, at 10:04 AM, Martijn Faassen wrote:

> Tres Seaver wrote:
> [snip]
>>> This is certainly an interesting approach. I'd be curious how you  
>>> would garden this known working set. Martijn makes a pretty good  
>>> case for maintaining such working sets close to the package in  
>>> question (e.g. the grok egg, the Plone egg, etc.).
>> I would argue that this problem is too big for "developer  
>> convenience"
>> to drive it:  we need concerted effort from the different  
>> "communities
>> of interest" to manage the problem, in much the same way that  
>> Debian /
>> Fedora etc. manage their various distribution releases.
>
> I want the ability to make releases of Grok so that when someone  
> writes an application against it, it will continue to work, no  
> matter what egg releases follow. That's a community of interest, I  
> guess? I just want the technical ability to do so, and easily. If  
> it's *not* convenient for developers to maintain it, it won't get  
> maintained well by the various communities of interest. I think  
> it's important to maintain these lists of dependencies close to  
> what they talk about, preferably inside the packages themselves.
>
> As far as I know what is required is the ability for grok, in its  
> setup.py, to include a list of suggested pinned dependencies  
> (besides, and separate from, the normal dependencies). It should  
> also be easy to configure buildout to inspect this list. What is  
> also required is a way to easily create and maintain this list.
>
> Now I think you're talking about ways to maintain, report and test  
> such lists below, but I want to solve my immediate problems first.
>
> I also need this solved preferably today. It's the primary hurt of  
> Grok today. Everything else is peanuts.
>
> Of course, if we don't need flexibility to allow application  
> developers to diverge from Grok's recommendation, this problem is  
> solved today, except for the bit to actually generate the list of  
> dependencies. We can simply hardcode them as dependencies in Grok's  
> setup.py and tell everybody who wants to use newer versions of eggs  
> for whatever reasons in their applications "too bad, wait for the  
> new release".

I'm skeptical that you are going to get these changes in setuptools.   
I'm not crazy about them myself as they make writing setup files even  
more complicated.  I'd much rather have a way for a comsumer to say:  
"Use version V of project P even though it doesn't satisfy a  
dependency."  Basically, a way to override a dependency.  This is  
something that buildout could be taught to do, although *I* don't  
have time to do it "today".

OTOH, buildout already provides an alternate solution to this, which  
isn't good enough because you want something that will work w/o  
buildout.  Oh well.

JIm

--
Jim Fulton
Zope Corporation




More information about the Zope3-dev mailing list