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

[Paul Moore]

2009/7/20 Jesse Noller <jnoller at gmail.com>:
> On Mon, Jul 20, 2009 at 5:38 PM, Paul Moore<p.f.moore at gmail.com> wrote:
>> 2009/7/20 Jesse Noller <jnoller at gmail.com>:
>>> So python -m "setuptools.commands.easy_install" <args> or python
>>> `which easy_install` is a-ok for people? I find it much easier to tell
>>> someone "run easy_install" or "run pylint" rather than either one of
>>> the previous examples.
>>
>> No, but "python -m easy_install" is fine. The fact that setuptools
>> doesn't provide a form designed for use with python -m doesn't mean
>> that there's a problem with the feature, just that setuptools wasn't
>> designed with it in mind.
>>
>> Paul.
>>
>
> I don't know if easy_install does or doesn't - I simply used it as an
> example. What I don't parse is that python -m <module> is somehow a
> replacement for ./script - the logic within a script can do a lot more
> than just firing off the __main__ of a module. Are we saying that
> "scripts are considered harmful" and recommend people only support -m
> for this?
>
> There's over 7000 packages, applications and libraries in the
> cheeseshop right now. A fair number of them would run face first into
> the non-versioned binary problem. I guess distutils (in a future
> version) should just deprecate the scripts/entry points options
> entirely?
>
> I really don't think this is an edge case, or should be unsupported.
> Sure, the same problem exists outside of the .local directory - you
> run into this installing things into the default system-level
> site-packages and /usr/bin /usr/local/bin directories, but there's no
> real reason we can't make this work better in the context of .local

My perspective is somewhat different, as I'm a Windows user, and many,
many cases where scripts are used don't work cross-platform.

Note: If you have a pure-python script foo.py, distributed with
package bar, why not just put foo.py on sys.path as part of the
install, and run it as python -m foo? How is that appreciably harder
than putting it in a bin directory?

Some cross-platform notes, which may not be obvious to people (if they
are obvious to you, my apologies - I don't mean to be patronising):

- Many Unix users don't like their scripts to end in .py
- Scripts that don't end in .py don't work on Windows
- .bat file wrappers on Windows have "odd" properties
- You made the point that the #! line is an issue on Unix

python -m module is cross-platform, and properly linked to the Python
version. It's less transparent than an executable script, but you have
to pick a compromise somewhere (and I appreciate that cross-platform
isn't always foremost in people's minds).

The biggest problem with -m is that not enough packages are designed
to support it. I hope I can add a "yet" to that, but it needs more
people seeing the benefits (you Unix people, remember us poor Windows
users! :-) :-)) if that's to happen.

Paul.

PS If you really want an executable script, you can always write an
alias or one-line shell script to do "python -m foo"... I don't know
if that suits your requirement.

PPS This is a defence of -m only, I don't have a view on the issue of
whether .local/bin should be versioned, as I don't use the feature
myself.