On 13 August 2013 21:20, Chris Barker - NOAA Federal <chris.barker@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...