Re: RFC: Known working sets

Hi Philipp,


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

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

> That said, Wichert's proposed solution to put the information in 
> EGG-INFO would make it open for use by other deployment tools, even 
> setuptools.

True.

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

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

Martin


-- 
Acquisition is a jealous mistress