On Tue, Aug 13, 2013 at 2:27 PM, Paul Moore <p.f.mo...@gmail.com> wrote:
>> 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 ouch! I don't think I'd want PATHEXT set for *.py files -- I'd rather they get opened by an editor by default than run...or is point+click behavior different than command line -- shows you how well I know Windows. > (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). There are those of us still in the 2.7 world -- and I suspect for a good while. > I'm suggesting that we collect specifics on any "fragility" (can you provide > details of what has gone wrong for you?) well, for PATHEXT, the env variable has to be set right, and Windows kind of hides all that from you -- it's really a pain to edit them by hand, so if the installer doesn't do it, or someone re-builds their registry or profile, or what have you, then it'll break. Oh and the cygwin (and who know what other shell alternatives) issue. At least we can pretty much count on an exe running if the shell can find it... Fragiity for the exe approach -- all I know is that the setuptools binary was proken a while back -- but setuptools itself was in a bit of a void of not-quite-sure-if-its maintained, and not-sure-even-how-to-report-a-bug state. It seems that setuptools (or whatever this will be part of) has now been adopted by the core Python community, so we can expect good support -- let's hope so. Anyway, whether the exe approach was more or less fragile than anyting else, is sure was harder to debug/fix for anyone that doesn't know Windows and non-python development well. >> 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"... well, I guess that's the way Windows does things -- *nix has the executable bit, Windows uses extensions, so I suppose that is "the way" to get an executable script -- but it really SHOULDN'T be *.py! > I think it's worth trying, though. agreed. I've lost track of what needs to be tried -- can't we just associate an extension with py and give it a go? (got to get that Windos VM working....) > 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. Good point -- it seem most of my scripts are part of a larger package, either a set of scripts, or a couple scripts that all rely on a particular package, so the whole setup.py thing works well. but for a single stand-alone script, the PATHEXT and py launcher approach seems really natural. > And many of the issues I've had with the exe wrappers are particular to > built installers (wheels, wininsts) and *not* develop mode. in theory, wheels and develop mode should do the same thing -- not sure about wininsts -- previously, the launcher thing was setuptools, not plain distutils, not sure how that was handled. but it would be best if they all did it the same way. > PS I still think that long-term a policy PEP on the recommended way of > making "executable scripts" is worthwhile. Probably, yes: "There should be one-- and preferably only one --obvious way to do it." I'm leaning toward the PATHEXT approach -- it seems more si milar to the *nix way, and perhaps easeir for lay folks to debug and fix. But I'm saying tha tthe exe method worked fine for many of us, too. -- 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.bar...@noaa.gov _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
