On 1/11/2013 7:10 AM, Jim Fulton wrote: > On Fri, Jan 11, 2013 at 6:31 AM, Chris Withers <[email protected]> wrote: >> On 11/01/2013 11:18, Jim Fulton wrote: >>> >>> On Fri, Jan 11, 2013 at 3:37 AM, Chris Withers<[email protected]> > ... >>>> - print the versions picked for any packages (as opposed to being >>>> specified >>>> by the buildout), in a format compatible with being pasted into >>>> buildout.cfg's versions section. This should happen by default. >>>> (when *wouldn't* you want this to be shown?) >>> >>> >>> In my case, most of the time. Most of my projects are library >>> projects. I never pin versions (or not all versions) in library >>> projects. >> >> >> Yeah, good call. Maybe a command line option rather than an option in >> buildout.cfg to get it to happen then? > > I don't think a command-line option makes sense. This should be on > or off on a project by project basis. For a given project, it should be > always on, or always off.
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'd hazard a guess that buildout is also a tool that you need rather than >> one you want to build (an important and painful difference). I may be wrong >> in that, in which case I again apologise. > > It's a tool I use on a daily basis and on which we (ZC) are building > interesting infrastructure. I'm proud of it and I think it can make some > meaningful contributions far beyond assembling Python applications. > So I'm not about to stop working on it. OTOH, it's grown unwieldy to > maintain and it's been too hard for me to work on it without simplifying it. > As a practical matter, that hasn't been a big problem for me over the > last few years because, even though it could be improved, it does > what I need. But buildout 2 *is* coming soon. :) I use it every day as well. It's indeed a great tool, thanks for the continued development. Personally, I'm all for breaking backward compatibility if it makes development easier. -- Eric. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
