whit wrote:
>> You could call it temporary in that Zope will hopefully get better at 
>> development eggs and therefore render a weaved-together bundle like this 
>> obsolete (instead, you'd have a bundle with eggs and then you'd 
>> easy_install each one). To be honest, I find the bundle fairly 
>> convenient though, just co and ln into lib/python.
> currently, the only thing that zope does wrong with eggs is 
> zope.testing.  if you use --test-path=/path/to/dev/egg, the test-runner 
> will even work with eggs(though this is super annoying).
> Now that the PYTHONPATH bug is fixed, you could conceivably just put the 
> "plone-lib" dir on the PYTHONPATH and zope could find it.  Personally, I 
> see this as a stop gap to doing the due diligence to get our own egg 
> story sanified(and we should fix zope.testing on the way).
> so really, this is our problem now, not zope's.

This is biting the Zope 3 people *right now*, too.  I wonder what
Philipp wrote in his the new edition of his book about eggs and tests.

I have been bitten by zope.testing too... :-/

> also, zope2 itself is just a few minor changes away from being egg 
> installable itself at which point we should be able to deal with 
> everything outside of Products via egg recipes.
> my opinion is a little elbow grease to get this worked out now rather 
> than later would go a long way. eggs are bit of pain, but we don't need 
> to wait for any zope gods to descend from on high to make things better.
> I mean... if you could say "easy_install Plone3=dev" and be ready to 
> work, how cool would that be? Kevin Dangmoor attribute much of TG's 
> success and rapid growth to making the packaging work.
> <rant off/>


I really hope I can put some time into this in the following days.


Framework-Team mailing list

Reply via email to