[Distutils] How to handle launcher script importability?

[Chris Barker - NOAA Federal]

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 at gmail.com> wrote:
> On 13 August 2013 18:08, Oscar Benjamin <oscar.j.benjamin at gmail.com> wrote:
>>
>> On 13 August 2013 17:33, Paul Moore <p.f.moore at 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 at 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 at noaa.gov