Making -m work for scripts
Hi, What do you think about making `python -m whatever` work also for installed scripts and not just for modules? I need this now because I've installed pypy on Linux, and I'm not sure how to run the `nosetests` of PyPy (in contrast to the `nosetests` of the system Python.) It's sometimes a mess to find where Linux installed the scripts related with each version of Python. But if I could do `pypy -m nosetests` then I'd have a magic solution. What do you think? Thanks, Ram.
On Jun 11, 2015, at 10:23, Ram Rachum <ram@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.)
On 12 June 2015 at 06:31, Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
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.)
Armin Ronacher's pipsi should already make it possible to do: pypy -m pip install pipsi pypy -m pipsi install nose In theory, that should give you a nosetests in ~/.local/bin that runs in a PyPy virtualenv (I haven't actually tried it though). "Should the default Python on Linux be a per-user configuration setting rather than a system wide symlink?" was also a topic that came up at this year's language summit (see https://lwn.net/Articles/640296/, especially the straw poll results at the end ), so it's likely a proposal along those lines will happen at some point during the 3.6 development cycle. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Jun 11, 2015, at 10:23, Ram Rachum <ram@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.)
On 12 June 2015 at 06:31, Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
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.)
Armin Ronacher's pipsi should already make it possible to do: pypy -m pip install pipsi pypy -m pipsi install nose In theory, that should give you a nosetests in ~/.local/bin that runs in a PyPy virtualenv (I haven't actually tried it though). "Should the default Python on Linux be a per-user configuration setting rather than a system wide symlink?" was also a topic that came up at this year's language summit (see https://lwn.net/Articles/640296/, especially the straw poll results at the end ), so it's likely a proposal along those lines will happen at some point during the 3.6 development cycle. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (5)
-
Andrew Barnert -
Antoine Pitrou -
Ned Batchelder -
Nick Coghlan -
Ram Rachum