Hi I see one major issue with this proposal:
Currently, the fact that the versions are in a standard buildout section, and subject to standard "extends" layering rules for buildout, means we have two great features: 1. You could locally override the versions file by just providing a few extra versions. 2. You could create partial buildout configurations for certain components that specify versions for certain components, and compose them with other configurations. An example that illustrates both: a buildout.cfg for Plone could extend the versions.cfg file for Zope 2.12.<latest> (served from a remote URL, no less) as well as its own versions.cfg (in this order). The latter would provide version pins for Plone components as well as tested overrides for more recent versions of Zope 2.12 components. Unless I misunderstand this proposal, there would could only ever be a single versions.cfg file for any buildout. This would require a lot more maintenance of this file than the current status quo. As such, I'd be strongly -1 on the current proposal. It can perhaps be improved, for example by allowing the 'versions-file' option be a URL list with similar semantics to "extends" but allowing += extension, and by making "update-versions-file" accept a file name, instead of a boolean. But I still feel like the current status-quo with a working buildout-versions would be better. Cheers, Leo _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
