[Zope3-dev] Re: Zope egg dependencies and tests

[Philipp von Weitershausen]

On 26 Apr 2007, at 09:27 , Christian Theune wrote:

> Am Donnerstag, den 26.04.2007, 08:40 +0200 schrieb Philipp von
> Weitershausen:
>> Christian Zagrodnick wrote:
>>> now there those wonderful eggs for Zope 3. Apart from the permission
>>> problem we ran into lately there is another one with those eggs:
>>>
>>> The dependencies aren't set right.
>>>
>>> Apparently nobody every ran the tests of those eggs. This is no  
>>> wonder.
>>> When developing you need to checkout Zope 3 instead of the egg  
>>> source.
>>> The Zope 3 tests would pass of course since everything is in  
>>> place there.
>>>
>>> I think we should move the actual code to the eggs as soon as  
>>> possible
>>> and put the externals into the Zope 3 source. Otherwise nobody  
>>> ever will
>>> run the egg tests.
>>>
>>> Also we need to take care of depending on certain versions. For  
>>> instance
>>> zope.location required a recent version of zope.proxy (>3.3).
>>
>> I personally don't like these "exclusive dependencies" that say  
>> what you
>> don't want. I'd rather spell it out as what I want. I think this
>> dependency should ready >=3.4.
>
> Well. This depends. If you want to enable eggs to work against  
> unstable
> releases then you need to do >3.3, because:
>
> 3.3 < 3.4dev < 3.4a < 3.4(.0)

Maybe, but:

   3.3 < 3.3.1 < 3.4dev etc.

So if you just specify ">3.3", 3.3.1 would satisfy this as well.

>>> And it's
>>> definitely better to say "I need >3.3 but can't find it" during  
>>> buildout
>>> than "zope.proxy has no module named decorator" somewhere when  
>>> starting
>>> the application.
>>
>> Agreed.
>>
>>> So, how do we get out of this? :)
>>
>> +1 on requiring running tests of individual projects
>>
>> Perhaps we could also automate this using a buildbot...
>
> *yikes*
>
> I'm not very fond of buildbot at the moment as it seems extremely
> fragile. In this case I'm more worried about the tests getting run *at
> all* than managing to run them on multiple machines.
>
> Lightweight administration is the key to this problem IMHO.

Yup. Low bar for contribution, too.