[Distutils] Merging buildout-versions in buildout

[Eric V. Smith]

On 1/11/2013 7:10 AM, Jim Fulton wrote:
> On Fri, Jan 11, 2013 at 6:31 AM, Chris Withers <chris at simplistix.co.uk> wrote:
>> On 11/01/2013 11:18, Jim Fulton wrote:
>>>
>>> On Fri, Jan 11, 2013 at 3:37 AM, Chris Withers<chris at simplistix.co.uk>
> ...
>>>> - 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.