Op 11-01-13 14:54, Eric V. Smith schreef:
On 1/11/2013 7:29 AM, Eric V. Smith wrote:
Here's my use case:
I run it once to determine what versions were picked (pointing to my own
find-links). I then take that list, occasionally massage it, and
manually put it into buildout.cfg under [versions]. My buildout's are
under control of a chef- or puppet- like configuration management tool.
Over time, with testing, I will modify the [versions] section in the
centrally controlled buildout.cfg, and my configuration management tool
will detect that change and automatically re-run buildout with the new
buildout.cfg, on possibly dozens of servers. On the servers, I never
want to produce a list of picked versions.
So for me, a command line option makes sense. I'd only use it while
doing initial setup or during testing of a new KGS. But it's not a big
deal: I can manually add this to buildout.cfg while I'm doing my
testing, and I'm editing buildout.cfg at that time, anyway.
I should have added: I'd be fine with the output only showing up on
stdout. No need to write it to a file, since I'm manually doing the
buildout.cfg integration, anyway.
I don't get the use case where you write to a file that's included
automatically by buildout (be that buildout.cfg or versions.cfg, or
whatever). Isn't that the same as just not specifying any pinned versions?
I don't use this, but supposedly that file is under version control and
you will commit the changes so there are no unpinned versions the next
time you run buildout.
So: at some point all your packages are pinned. Then you add a package
in your buildoud config, run buildout, and you commit the extra package
plus the automatically added version pin, including pins for any extra
dependencies pulled in.
--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
