[Distutils] Merging buildout-versions in buildout
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
> 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
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
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
> 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
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 --
Do we actually know anyone who would take that money though?
Simplistix - Content Management, Batch Processing & Python Consulting
More information about the Distutils-SIG