[Python-ideas] Changing the default install location, script versioning (Packages and PEP 370)

Paul Moore p.f.moore at gmail.com
Tue Jul 21 19:36:50 CEST 2009


2009/7/21 Brett Cannon <brett at python.org>:
> Taking Paul's follow-up email to this into account, I think we should
> definitely encourage people support runpy, but that doesn't do away with the
> usefulness of scripts. Ignoring the convenience factor of having short
> script names (``hg tip`` is much shorter than ``python2.6 -m mercurial --
> tip``), there is also having to remember which interpreter you installed a
> tool under. Did I install hg under my Python 2.3, 2.4, 2.5 or 2.6
> interpreter? I actually had to check the hg script to find that out.
> And there is also the situation where people are not targeting multiple
> operating systems and thus have a use for the features a script gives. If I
> am writing some Linux app in Python I might have some need to run something
> under bash.
> So while I totally support pushing people to start using runpy now that
> __main__.py support exists for packages, I don't think we can just fluff off
> script support.

Just to clarify - my personal view ("tainted" by Windows experience,
certainly) is that *applications* (such as Mercurial) should be built
as isolated, standalone executables, bundled with something like
py2exe. I fully appreciate that this is the precise opposite of common
practice on Linux (see below for some uninformed speculation on that).

I see runpy as being appropriate for the types of small "supporting"
scripts that come with general-use packages - things like Twisted's
twistd, Nose's nosetests, etc. Essentially, where the package is the
key thing, and the command is a related utility. When the command is
the main focus, I see that as an "application".

I don't know the right answer for "applications" under Linux, but I
don't see any reason why a wrapper shell script wouldn't work - it's
no less portable than a py2exe built executable. Installing a wrapper
is then the responsibility of the packaging system, rather than
Python. But as I say, my expertise is basically zero here.

Paul.



More information about the Python-ideas mailing list