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.
Alas, not so for all Plone people: Some folks prefer workingenv's in
old-fashioned Zope (2) instances, some people use instancemanager, some
people still symlink into lib/python.
Well, then let me rephrase: I'm not looking for a solution that fits
everybody. I'm looking for *a* solution. And I wouldn't mind if it
worked well with zc.buildout :).
Plus, a ConfigParser-style configuration file can be read by pretty much
anything so I'm sure workingenv, instancemanager and what not can
easily be enhanced if someone cared enough. And as said before, if the
stuff is placed in EGG-INFO, it'll also be extremely easy to discover.
Also, working sets have "deployment" written all over it.
Good point.
setuptools has little to no machinery to aid automated deployments in
any way.
True. However, I think it's also legitimate to want to "depend on" a
complete "working set", which is more in setuptools land. But I see no
problem in solving this at a buildout level first.
setuptools only gives us the ability to depend on eggs. Working sets as
ar as I define them are pinned down version definitions of dependencies.
This doesn't exist in setuptools yet. The fact that we can use its
dependency mechanism as an analog is pure convenience.
- 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 plone.recipe.plone.
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.
Yeah, true. It's just that everything wants to be the "one true place".
In the Plone land, having to cater to non-buildout deployments may make
that harder, but like you said - .cfg files are pretty neutral.
Yup. Non-buildout deployments, such as installers, could still read the
.cfg file from EGG-INFO.
- 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 specifications, though.
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).
Right.
Anyway, like I said - I'd like to see a working version of this
approach; Plone could quite usefully use it, imho.
I trust by "this approach" you mean the EGG-INFO approach? Because the
stuff I proposed originally already works...
--
http://worldcookery.com -- Professional Zope documentation and training
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
