Just $0.02 from a user... I'm primarily an OS-X user these days, but have to do Windows once in a while, and help others do Windows (including as an intro to Python instructor) Once I discovered setuptools "develop" mode, I never looked bak -- it is simpl;y THE way to develop code, particularly if you are working on a lib you want to use from other projects and/or actively develping utility scripts. I really like that I can add some scripts to setup.py, and use either develop mode or regular old install and get nice commands, and it works the same way on Windows and *nix (with the hood closed0 I did all this for a good while before I even noticed that exe launchers -- it "just worked". In fact, the only time I noticed the launchers was a couple years ago when a beta version of setuptools released a broken version -- very frustration -- it would fire up another command window that would then close when the script was done -- not very helpful for nosetests and the like... When I did discover how it all worked, I did think it was a little weird, but Windows simply hasn't been built for command line stuff, so you do what you have to do. Conclusions: 1) an extra bunch of files is a on-issue for most users -- we just need something that works. 2) the exe launcher is a bit fragile and hard to maintain (and even harder to debug) -- but there are smart people working on this. 3) I'd rather not have to mess with PATHEXT, and I particularly don't want to have to tell my students to do it -- environment variables are a pain, and somehow PATHEXT has been fragile for me (and I don't use Cygwin) I cant help thinking a more elegant solution exists, but maybe not. Thanks to everyone hashing this out! -Chris On Tue, Aug 13, 2013 at 12:58 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 13 August 2013 18:08, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
On 13 August 2013 17:33, Paul Moore <p.f.moore@gmail.com> wrote:
On another point you mention, Cygwin Python should be using Unix-style shell script wrappers, not Windows-style exes, surely? The whole point of Cygwin is that it emulates Unix, after all... So I don't see that as an argument either way.
So say I have a ~/bin directory where I put my scripts that I want to be generally available. I install something with python setup.py install --install-scripts=~/bin so that the scripts/script-wrappers go in there because I want to be able to always access that program under that name. Don't be fooled by the unixy tilde: I'm running ordinary Windows Python in that command in git-bash, not Cygwin. Now if that folder is on PATH while I am in Cygwin I can run the program with the same name if an .exe wrapper was added. I can't run it with the same name if it's a .py/,bat file because Cygwin doesn't have the implicit strip-the-extension PATHEXT feature and can't run .bat files.
Ah, OK, thanks for the clarification.
In that case I can see why you'd prefer exe wrappers (or maybe cygwin bash shell wrappers, or shell aliases...). Maybe an option to still use exe wrappers is worth it - but honestly, I'd say that in that context you probably have enough expertise to understand the issue and make your own solution relatively easily.
What about having in your .bashrc:
for prog in ls ~/bin/*.py; do alias $(basename $prog .py)=$prog done
(Excuse me if I got the precise details wrong there). OK, you need to rerun .bashrc if you add new scripts. It's not perfect. But it's not a showstopper either.
I do think, as I said before, that this needs some sort of policy-type PEP on the standard approach for wrapping scripts, with all the pros and cons of the various approaches documented and reviewed.
Paul
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov