Hi everyone, I'm sure there's a clear answer, probably written some place obvious, but I wonder if there is a reason why certain functions are not linked to console_scripts. In particular I would think this would be good for json.tool (though I might call it something else, like pyjson_pp). Same with venv. I'm sure I'm missing something obvious. Thanks, Eliot
On 20 Feb 2022, at 08:56, Eliot Lear <el+py@lear.ch> wrote:
Hi everyone,
I'm sure there's a clear answer, probably written some place obvious, but I wonder if there is a reason why certain functions are not linked to console_scripts. In particular I would think this would be good for json.tool (though I might call it something else, like pyjson_pp). Same with venv. I'm sure I'm missing something obvious.
You can use from the CLI like this for modules that a __main__.py has been provided. This includes pip, json, venv, tarfile and zip file (off the top of my head). python -m pip list python -m json <jaon-file> python -m venv etc. On windows you would use py not python for preference: py -m pip list etc. This is documented for the modules I named above. Is that what you are after? Barry
On Sun, Feb 20, 2022 at 09:56:18AM +0100, Eliot Lear wrote:
Hi everyone,
I'm sure there's a clear answer, probably written some place obvious, but I wonder if there is a reason why certain functions are not linked to console_scripts. In particular I would think this would be good for json.tool (though I might call it something else, like pyjson_pp). Same with venv. I'm sure I'm missing something obvious.
Hi Eliot, What do you mean by "linked to console_scripts"? Are you referring to the packaging feature? https://python-packaging.readthedocs.io/en/latest/command-line-scripts.html If you are, I expect that the answer for why some functions aren't linked to console_scripts could be that: 1. Not all functions would be useful as command line tools. 2. Nobody has done the work to make it possible. 3. If a Python package already defines a `__main__.py` file in the package, you can call it as a CLI tool with `python -m package`. So making it a separate CLI tool is redundant. In the case of packages that are part of the Python stdlib, linking them to a stand alone CLI tool is more of a decision for the OS than for Python itself. On Linux, I think that the Linux distribution decides whether or not to include CLI tools for Python, and what they are called (e.g. whether or not the commands "idle" and "pip" exist). I don't know what happens on Mac and Windows. There is some evidence that stand-alone scripts (such as pip, and idle) are harmful. If you have many different versions of Python installed, as some people do, calling pip is not guaranteed to install into the version you were expecting. Same for launching idle, which may not run the version of Python you were hoping for. For example, on my system, my preferred version of Python 3.10, but `pip` installs into 2.7, and `idle` doesn't exist at all. But I can run the correct versions with `python3 -m pip` and `python3 -m idlelib`. My guess is that you may get better answers to your question if you ask it on the Packaging Discussion forum: https://discuss.python.org/c/packaging/14 -- Steve
On 21Feb2022 09:12, Steven D'Aprano <steve@pearwood.info> wrote:
On Sun, Feb 20, 2022 at 09:56:18AM +0100, Eliot Lear wrote:
[...] I wonder if there is a reason why certain functions are not linked to console_scripts. In particular I would think this would be good for json.tool (though I might call it something else, like pyjson_pp). with venv. I'm sure I'm missing something obvious. [...]
[...] 1. Not all functions would be useful as command line tools.
2. Nobody has done the work to make it possible.
3. If a Python package already defines a `__main__.py` file in the package, you can call it as a CLI tool with `python -m package`. So making it a separate CLI tool is redundant.
A fourth reason is that one shouldn't be too profligate with installing scripts in the command line path. That "space" includes not just Python tools but every other command you could invoke - as a global namespace it is easily polluted. The previously mentioned "python -m module_name" command line mode provides precision here, particularly if you adjust the word "python", without polluting the command line space. That said, it isn't always a bad thing to provide a script. I do it myself. Choosing an name which is (a) expressive and (b) less likely to conflict with other's choices is important though. Cheers, Cameron Simpson <cs@cskk.id.au>
As it seems there's a more appropriate list to take this, I'll just say thanks to all who replied with great information and thoughts and leave at that for now. Eliot On 21.02.22 00:40, Cameron Simpson wrote: > On 21Feb2022 09:12, Steven D'Aprano <steve@pearwood.info> wrote: >> On Sun, Feb 20, 2022 at 09:56:18AM +0100, Eliot Lear wrote: >>> [...] I wonder if there is a reason why certain functions are not >>> linked to console_scripts. In particular I would think this would be >>> good for >>> json.tool (though I might call it something else, like pyjson_pp). >>> with venv. I'm sure I'm missing something obvious. [...] >> [...] >> 1. Not all functions would be useful as command line tools. >> >> 2. Nobody has done the work to make it possible. >> >> 3. If a Python package already defines a `__main__.py` file in the >> package, you can call it as a CLI tool with `python -m package`. >> So making it a separate CLI tool is redundant. > A fourth reason is that one shouldn't be too profligate with installing > scripts in the command line path. That "space" includes not just Python > tools but every other command you could invoke - as a global namespace > it is easily polluted. > > The previously mentioned "python -m module_name" command line mode > provides precision here, particularly if you adjust the word "python", > without polluting the command line space. > > That said, it isn't always a bad thing to provide a script. I do it > myself. Choosing an name which is (a) expressive and (b) less likely to > conflict with other's choices is important though. > > Cheers, > Cameron Simpson <cs@cskk.id.au> > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-leave@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HD6TQC22ORI3T6RPWDD7FQIIA57U236E/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
participants (4)
-
Barry Scott -
Cameron Simpson -
Eliot Lear -
Steven D'Aprano