[Distutils] Merging buildout-versions in buildout

Jim Fulton jim at zope.com
Fri Jan 11 13:10:38 CET 2013

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.

>> a) No one proposed a file compatible with pip.
>>       I proposed a file that was not a buildout configuration file to
>> avoid
>>       requiring "versions = versions", which has become a rather pointless
>>       incantation.
> Indeed, but the feedback I've seen suggests making [versions] a standard
> section like [buildout] would be a better way to go.

Possibly. I'm definitely open to that for buildout 2.

>> In any case, no one seems to have embraced my proposal, so I'll
>> take another stab at it (in a separate email).
> The main thrust of this mail you're replying to was the proposal I want to
> implement, what don't you like about it?

Sorry, I didn't see a proposal.  Maybe I missed it.

AFAIK, you proposed to incorporate buildout-versions into
buildout, but you didn't propose how.  The UI would definitely
have to change, because it would no-longer be an extension.


> 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. :)

>>> the dropping of Windows support (yeah, I hate
>>> windows too, but its still used enough that I need to support it,
>> Windows support hasn't been dropped.
> I read an email from you implying it was, maybe I got the wrong end of the
> stick...

The email you read said someone else needed to step forward
because I have my limits.


> I really hope we can find a way to solve the forking problem that
> means I have to put in a shell wait on windows when I use buildout and
> buildout finds a new version of itself...

I don't know what you're referring to.


Jim Fulton
Jerky is better than bacon! http://zo.pe/Kqm

More information about the Distutils-SIG mailing list