On 15 July 2013 17:47, Chris Barker - NOAA Federal <chris.barker@noaa.gov> wrote:

I don't _think_ this is just Windows Bashing: MS has done very very
little to improve the whole command line experience on Windows over
the years.

It's not MS-bashing. I agree with you, and I'm one of the least likely people around here to indulge in arbitrary MS-bashing. (With the exception of Steve Dower, I guess :-)) Powershell is a *great* step up from cmd, but there are still a lot of dodgy bits round the edges (mostly because of the whole "console vs GUI subsystems" thing).

All that is a way to say that Python can only make it so easy for
Windows users, but what's in place is not bad, and it really makes
sense for pip to use what's been there for ages, i.e. a command called
"pip" (and pip2, pip3...) that sits in the same place that all other
third-party Pyton "scripts" are installed. No matter how you slice it,
a user will need to put that on their PATH one way or another.

Agreed, PATH manipulation is a fact of life for everyone, both Unix and Windows.

Of course, what MS is telling us is: don't rely on the command line!
So a really nice thing to do for Windows users would be to provide a
little GUI pip tool that's part of the standard install. (not that I'm
volunteering to write it...has no none yet written a tkInter-bsed pip
front-end?)

I don't think a GUI-based tool is the answer here - the command line is orders of magnitude more powerful. For simple cases yes, but we have bdist_wininst and bdist_msi for those, and they are clearly not enough.

the current setuptools exe-wrapper feels really kludgy, but it works
-- it seems the only real problematic issue is the self-update problem

The self-update issue is the big one. There are others (completely incomprehensible errors if the #! line in the script is wrong, for example) but it's certainly pretty much the best solution we have at the moment. Most of my problems with the setuptools wrappers are not actually with the exe, but rather with the actual script (and its dependency on pkg_resources) that lies behind it - and that's not a Windows problem per se.

-- maybe there is a Windows guru somewhere that can fix that....

I think I'm that guru, unfortunately, and I'm not having a whole lot of luck :-)

The real problem is not technical, actually - it's knowing what Windows users will actually be comfortable with. Unix users tend to assume Windows users are very uncomfortable on the command line (no offence meant to anyone by that) whereas the reality is that some are, some (like me...) really are not, and some are simply unfamiliar with the capabilities of the Windows command line through lack of need to use it (many of my colleagues, for example).

I'm actually tempted to give up trying to please everyone, and just put together a solution that suits *me* and see how that flies. Second guessing what other people want makes my head hurt :-)

Paul