[Distutils] Merging buildout-versions in buildout

[Jim Fulton]

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

>
> After reading all the discussion, it sounds like the approach
> buildout-versions currently takes is the one that's going to give the most
> milleage:
>
> - 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.

...

> While I like the idea of a versions format compatible with pip*, it sounds
> like that would kill off the extends interaction, which would be bad.

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.

b) The proposal offered the new file in **addition** to the existing mechanism.
     No one proposed killing off the extends mechanism.

In any case, no one seems to have embraced my proposal, so I'll
take another stab at it (in a separate email). Then again, if you're
no longer interested, I might not bother.

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

> 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. 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.  The typical pattern is that
someone contributes code to a project, windows tests start failing and
I spend hours or days cleaning it up.  This happend to buildout 1 and,
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.)

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.  I doubt I could recreate it today at least not without
spending a bunch of money on Microsoft tools or a bunch of time on
free tools that almost work.  There seems to be an offer of free MSDN
subscriptions to Python contributors that could improve the situation
for me. We'll see.

Buildout doesn't even build on windows on Python 3.  Between windows
and Python 3, I'm just not motivated to dive into it.

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. I care, but I have limits.

Jim

--
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://zo.pe/Kqm