[Distutils] Merging buildout-versions in buildout

Chris Withers chris at simplistix.co.uk
Fri Jan 11 12:31:15 CET 2013

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>  wrote:
>> Hi All,
>> My take on this, as the person who may or may not have offered to do the
>> work...
> Um, this whole discussion started because you said:
> "Jim, if I worked up a pull request would you merge it?"

Missed smiley, I definitely offered ;-)

>> - 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?

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

> 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?

>> * I have to admit to currently thinking hard about migrating away from
>> buildout; its development has been hampered by people with not enough time
>> trying to solve hard problems,
> Well, I've spent a lot of time.  It's nice to see it's appreciated.

My statement was carefully worded, sounds like I should have explained 
it: I did *not* say a lot of time had not been spent; I absolutely 
appreciate all the work you've done and if what I said implied 
otherwise, I apologise profusely and unreservedly.

However, a lot of the stuff added by people other than you to buildout 
has been done with the time they had available (not enough) and to solve 
their own needs (hard problems) at the expense of the code base and 

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.

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

> Last time I checked, tests passed
> on the git master on Windows for Python 2.
> Aside from testing web apps in Windows browsers, the only reason I
> touch Windows is to try to make sure various open-source Python
> projects I work on work on Windows.

We live in the same world :-)

> having spent a lot of time trying to figure out the breakages, I have
> up. (A major thrust or buildout 2 is to simplify the implementation to
> make it more maintainable.)

Cool, 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...

> Meanwhile, I am not a windows developer.  I have a very old Windows VM
> that I set up years ago with the help of documentation prepared by Tim
> Peters.

Well, okay, I'm one up, I have a real windows machine (thanks to a 
cantankerous sound card in a studio) but as far as compilers and things 
go, no idea...

> At some point, someone who cares about windows is going to have to
> step forward.  If you aren't a developer, pay someone who is --
> whatever.

Do we actually know anyone who would take that money though?


Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

More information about the Distutils-SIG mailing list