[Distutils] How to handle launcher script importability?

[Paul Moore]

On 13 August 2013 21:20, Chris Barker - NOAA Federal
<chris.barker at noaa.gov>wrote:

> Conclusions:
>
> 1) an extra bunch of files is a on-issue for most users -- we just
> need something that works.
>

Agreed - the extra files "clutter" is a relatively small issue.

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

Nobody is really working on the launcher itself AIUI. The code is pretty
much static, except when it breaks (for example, the whole UAC/manifest
issue).

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)
>

Nobody is suggesting that end users mess with PATHEXT. The proposal is that
the Python installer does this (indeed, that's been done for Python 3.4, I
don't know if the installer for the standalone launcher has been updated in
the same way yet).

I'm suggesting that we collect specifics on any "fragility" (can you
provide details of what has gone wrong for you?) so that we can document
and address any genuine issues. But without specifics, we're currently
faced with nothing more than a two-pronged "I think it might not work"/"why
change it if it works at the moment" argument that has nothing we can
actually address... (Not criticising anyone here, it is often hard to be
specific).

I cant help thinking a more elegant solution exists, but maybe not.
>

Personally, I believe that executable .py scripts (or maybe a dedicated
.pys/.pye/.pya/whatever extension) *is* a more elegant solution - but
equally, I concede, "maybe not"...

I think it's worth trying, though.

Also, you mention develop mode. I don't use develop mode, most of my
standalone scripts are single-file scripts, not anything that I'd bother
packaging up with a setup.py, etc. Or I run them via python -m, or I
install a supporting package and have a (standalone, as previously) driver
script. And many of the issues I've had with the exe wrappers are
particular to built installers (wheels, wininsts) and *not* develop mode.
Those also need to be classified precisely and reviewed - I don't claim
they are any more important than the issues you mention with pure scripts -
but I'd prefer that we understand the trade-offs and make an informed
decision. It may even be that different solutions are better depending on
how you work (develop mode vs installing).

In the interests of getting more concrete data, can I suggest that
setuptools add an off-by-default option, which can be set globally using a
config file or environment variable or something (so that it can be used
transparently by tools like pip) to use scripts rather than exe wrappers?
People can then try it and see whether they hit issues with it. Otherwise,
I think we're going to remain forever stuck with theorising and guesswork.

Paul.

PS I still think that long-term a policy PEP on the recommended way of
making "executable scripts" is worthwhile. As I've said, if no-one else
wants to pick it up, ask me again in October or so...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130813/1d94ad3d/attachment-0001.html>