>> 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