On Mon, Jan 7, 2013 at 6:12 AM, Maurits van Rees <m.van.r...@zestsoftware.nl> wrote: > Op 05-01-13 23:47, Jim Fulton schreef: >
... >> 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. > > > A section header should be permitted too, specifically '[versions]', so it > is just a normal buildout file. Why? A makor point of this proposal is that it isn't a buildout configuration, so it doesn't need a header and you don't have to use a buildout section. You still *can* have a buildout section, which the buildout-file augments, ut you don't have to. > > Would this file be implicitly added at the end of the 'extends' list? Or > would the user still need to do that explicitly. No, because it's not a buildout configuration file. > I always just let buildout-versions or buildout.dumppickedversions print the > picked versions and when I agree I paste them in versions.cfg or another > buildout file. This would still be supported. ... >> 3. The ``allow-picked-versions`` option gets a new allowed value of >> ``warn``. if there are unpicked versions and this option is set to >> ``warn``, then picked/unpinned versions are reported. Also, if >> ``allow-picked-versions`` is true, there will be no error if >> ``update-versions-file`` is true. > > > +1. In a development setup I would probably set this to 'warn' and in > production to 'false'. > > Say there is a buildout config with one or more versions that are not > pinned. What would the effect be of the various options? Here is a truth > table: > > allow-p-v update-v-f result > > false false buildout quits with error > > false true buildout quits with error No, as described in the proposal, if update-versions-file is true (and assuming that you've specified a versions-file) then there would not be an error if allow-picked-versions was false and there were picked versions, because they'd be added to the versions file and thus would become un-picked. > > warn false buildout reports versions on stdout Yes, in a format convenient for copying into a versions configuration or versions file. > > warn true buildout edits versions file > > true false buildout reports versions on stdout No. > true true buildout edits versions file > > From that, I wonder if there is a practical difference between > allow-picked-versions being set to 'warn' or 'true'. Perhaps when it is > true and update-versions-file=false (row 5), you do not want to print > anything? Right. 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
