On Sun, Jan 6, 2013 at 7:38 PM, Alex Clark <acl...@aclark.net> wrote: > On 2013-01-05 22:47:05 +0000, Jim Fulton said: ... >> >> versions = versions >> >> [versions] >> ... > > > This is confusing… but I was thinking more along the lines of adding a > default setting "versions = versions", at which point end users need only to > add a section named [versions].
That would make the section named "version" reserved. This would be backward incompatible, which is why I didn't do it that way to begin with. Of course, buildout 2 provides an opportunity to change things in a backward-incompatible way. ... >> Based on this, I propose that buildout-versions get incorporated into >> buildout in the following way: >> >> 1. New buildout option named ``versions-file`` which takes the name of >> a file. to contain version information. It is not a configuration >> file. It is a file consisting of comments (#...) and version >> specifications:: >> >> # whatever >> foo = 1.3 >> >> If it doesn't exist, it wil be created. (I'm not sure it's a good >> idea to create the file implicitly though.) Any version constraints >> found in the file are added to the buildout version constraints. >> Version constraints found in the versions-file override version >> constraints obtained via a versions option, if any. > > > > +0 And if you do this, it may cause confusion with folks familar with the > current practice. Is it possible to support both? The proposal augments the current machinery. You will still be able to define a versions section. > (At the very least, I'd > make Buildout always use versions specified inside a [versions] section i.e. > by making "versions = versions" the default.) As mentioned above, this would be backwards-incompatible, >> 2. New buildout option: ``update-versions-file``. If this is true, >> then any picked/unpinned versions are appended to the versions file >> and reported in the output. There's a command-line option, ``-V`` >> to set this to true for a run. It's an error to use this if >> ``versions-file`` isn't set. > > > > So this helps encourage folks to pin versions by auto-generating the > versions file and using it on subsequent runs? It doesn't encourage them to pin versions, it just makes it easier. > To give some real world > context, IIUC I can create a buildout: > > [buildout] > update-versions-file = true > parts = zope2 This would be an error, since you haven't specified a versions file. Also, I don't expect people to set update-versions-file in their buildout.cfg, but rather to turn it on via a command-line argument. > [zope2] > recipe = zc.recipe.egg > > > If I run this, I'll get a versions.txt file If you also included: versions-file = versions.txt in your buildout section. > with ZTK packages in it (but not > necessarily the packages required to run Zope2, since Zope2 itself does not > know about its own KGS i.e. > http://download.zope.org/Zope2/index/2.13.19/versions.cfg. And subsequently > PyPI will return the latest version of each install_requires value.) In the example above, the versions.txt file would include versions for Zope2 and all its dependencies. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
