Update creating-command-line-tools.rst to fix typo

[arrowtype]

The import statement in cli.py, as written, fails. It doesn’t match the name of the file (greet.py) that is set up with the greet() function.

An alternative solution would be to edit the name of greet.py to be hello.py, which I could also imagine being a useful approach, to avoid potential ambiguity from repeated words in different places. I chose to submit the simpler fix, though.

(By the way, thank you for this amazing guide! It’s so clear and helpful.)

One further thought/question: maybe it would be helpful to say that this can also be installed with pip? I wasn’t sure if I could just use pip and a venv, but didn’t want to add another layer of complexity to my setup, so I tried. And, sure enough, pip and a venv will install this, no problem! I get that you want to present a single, simple path, however, so I can understand just mentioning pipx if that seems like the best choice.

[chrysle]

Thanks for catching this! It was left over from some refactoring work. I chose this file and function name in the end to match the package name, which I prefer to hello.

(By the way, thank you for this amazing guide! It’s so clear and helpful.)

Glad to have helped!

One further thought/question: maybe it would be helpful to say that this can also be installed with pip?

The basic idea was to promote pipx since using pip has become practically a nuisance on many Linux systems (for most needs), as you said. But feel free to add a note mentioning this, probably even in the linked pipx guide itself, with a practical example. Sidenote, you'll hopefully soon be able to use different backends than only pip and venv (pypa/pipx#1487).

[arrowtype]

Glad to help out!

The basic idea was to promote pipx since using pip has become practically a nuisance on many Linux systems (for most needs), as you said. But feel free to add a note mentioning this, probably even in the linked pipx guide itself, with a practical example. Sidenote, you'll hopefully soon be able to use different backends than only pip and venv (https://github.com/pypa/pipx/pull/1487).

Oh wow, a lot of this is new info to me – thanks for sharing that thinking and those details! TBH, I don’t feel familiar enough with the pros and cons of pip vs pipx to feel comfortable adding information around it to the guide. I’m only really familiar with macOS, but if pip is causing issues for folks on Linux, it seems sensible enough to recommend something else, as you have.

[sinoroc]

pip has become practically a nuisance on many Linux systems (for most needs), as you said.

but if pip is causing issues for folks on Linux, it seems sensible enough to recommend something else, as you have.

I do not think this framing is fair. What is happening is that a lot of people are not comfortable with using pip+venv, in particular when the only thing they want is to install and use an application (as opposed to write code in Python). Then they try things that they see online and end up potentially messing up their system (typically with commands like sudo pip install some-application without using a virtual environment). Enter pipx. pipx makes the process of installing and using Python applications much easier.

pip and venv themselves are far from being nuisances, they play their role perfectly fine as expected, but I would argue that they are developer tools rather than end-user tools. It is when end-users (mis)use pip+venv that things can go (very) wrong.

[chrysle]

I do not think this framing is fair.

Sorry, perhaps the wording is a bit harsh. I only wanted to say that actually using these tools on systems that opted in to PEP 668 has some practical drawbacks now, which is why I (and most people) prefer using pipx.

What is happening is that a lot of people are not comfortable with using pip+venv, in particular when the only thing they want is to install and use an application (as opposed to write code in Python). Then they try things that they see online and end up potentially messing up their system (typically with commands like sudo pip install some-application without using a virtual environment).

Of course I agree that separating Python and OS environments is a good thing, although I haven't experienced any issues myself and found the concept of user installs reasonable. Still, the additional safeguard prevents users from damaging their systems, so is for the better.

It is when end-users (mis)use pip+venv that things can go (very) wrong.

Of course that is true.