[Python-ideas] Making -m work for scripts

[Andrew Barnert]

On Jun 11, 2015, at 10:23, Ram Rachum <ram at rachum.com> wrote:
> 
> What do you think about making `python -m whatever` work also for installed scripts and not just for modules?

The current packaging system already makes it easy for packages to make everything easy for you. Assuming nosetests is already using setuptools to create console script entry points automatically, all they have to do is make the top-level code in the module/__main__.py in the package call the same function specified as the entry point, and `pypy -m nosetests` now does the same thing as `/path/to/pypy/scripts/nosetests` no matter how the user has configured things. That's probably a one-line change. (If they're not using entry points, they made need to first factor out a `main` function to be put somewhere that can be used by both, but that still isn't very hard, and is worth doing just so they can switch to using entry points anyway.) Many packages already do this. The obvious problem is that some don't, and as an end-user your only option is to file enhancement requests with those that don't.

I don't think there's any obvious way to make your idea work. Python doesn't keep track of what got installed where. (I believe it could import distutils and determine the default install location for new scripts, but even that doesn't really help. Especially since you can end up with multiple Python installations all sharing an install location like /usr/local/bin unless one of those installations does something to avoid it--for example, on a Mac, if you use Apple's pre-installed 2.7 and also a default install from python.org, they'll both install new scripts there.)

Of course the pseudo-database of installed scripts could be migrated from pip to Python core, or pip could grow its own script runner that you use in place of Python, or there are probably other radical changes you could make that would enable this.

But if we're going to do something big, I'd prefer to just make it easier to specify a custom script suffix in distutils.cfg and encourage distros/users/third-party Pythons/etc. to use that if they want to make multiple Pythons easy to use, instead of using different directories. Then you'd just run `nosetests_pypy3` vs. `nosetests3` or `nosetests_jy2` vs. `nosetests2` or `nosetests_cust3.4` vs. `nosetests3.4` or whatever. (Mainly because that's what I do manually; I have a wrapper around pip that symlinks any installed scripts into /usr/local/bin with a suffix that depends on the wrapper's name, and symlink a new name for each Python I install. I'm not sure if anyone else would like that.)