On 11/01/2013 11:18, Jim Fulton wrote:
On Fri, Jan 11, 2013 at 3:37 AM, Chris Withers<[email protected]> 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
documentation.
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?
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
