IMHO real answer isn't to use "go get" instead of "pipx install"; the answer is to use Go to build statically-linked binaries and then to distribute those binaries with an OS-level, language-agnostic package manager (e.g. Homebrew or apt-get).

Why do you need a package manager if you have a statically linked executable? Can't you just save it in ~/bin and have that in PATH? (Users who can't do that shouldn't be using CLI would be the argument I guess.)

So that people can install and update the tools via the same habits they’ve already learned.

> Users who can’t do that shouldn’t be using CLI

Users who can do that will still find it an odd departure from convention.

I second having an internal PyPI. Not requiring your customers to build your platform wheels for you simplifies Python distribution quite a bit.

It'll never be as clean as a static binary build, but it saves us from having to build out two language ecosystems when the rest of the company uses Python for everything.

And when your client has a slightly different python install or some other library which deps on an older incompatible version of a lib... Then what?

Python is awful for this stuff

Don't disagree. It's a problem. As the parent poster and others have mentioned, you can use something like pipx, or bare virtualenv. At least once I've deployed via dh-virtualenv and rpmvenv, pyinstaller, cx_freeze, or tested for compatibility with the system Python if I could control for the client machines.

It's never fun. It's never pleasant. But to be fair, if I have a CLI tool that needs a deployed SSH client, or Tensorflow, or SDL or Qt or something else, I'm not convinced packaging gets much easier no matter what language we're talking about. If your use case is simple, Python is easy enough to deploy, and Go is even easier. If you can't disable CGO or need a third party component, I imagine the fun is just getting started anyway.

As a counterpoint, awhile back, discovered that Golang had a minimum kernel version requirement. That pretty much eliminated it as a possibility for writing tools for legacy systems. Python was viable though, Bash moreso. :) Couldn't tell you if that was still a requirement for Go today.

All good comments. I should have noted that my comment was not regarding Python (which I have little real-world use) and meant to apply more generally to utility or in-house tooling should be as easy to install and use as possible. Being that it's not the main focus of development, it will bitrot so anything you can do to guard against it is worthwhile, and a single compiled Go binary is hard to beat in that regard.