Martin Aspeli wrote:
- It only works through buildout. Ideally it would be supported at the
setuptools level, imho.
I'm not really convinced that that's necessary. From a practical
perspective, zc.buildout is the defacto deployment tool in the Zope
community. Also, working sets have "deployment" written all over it.
setuptools has little to no machinery to aid automated deployments in
That said, Wichert's proposed solution to put the information in
EGG-INFO would make it open for use by other deployment tools, even
- I worry that the management of lots .cfg files could be cumbersome.
For Plone, we could probably generate one from the dist_plone package,
which otherwise lists "known working sets" for installers and
Well, or the other way around: the installers could take the .cfg file
of the working set and grab the right packages according to that. After
all, a .cfg file can be read with ConfigParser quite easily.
- This doesn't really solve the dependency problem. I can't say, "Give
me Plone 3.0.1 or newer" in a third party package. That could probably
done by having a separate "Plone" meta-egg which uses >= type dependency
Yes, this could be covered by a Plone egg (meta or not) and a
"Plone>=3.0" modifier that's put in the 3rd party package's setup.py (I
think the >=, <= operators can be valid in setup.py, just == isn't).
http://worldcookery.com -- Professional Zope documentation and training
Zope3-dev mailing list