I get what you mean with the Python tools, but I've had a good experience distributing tools with an internal pypi and pipx. Then users do "pipx install <package>" from the README, voila, commands work.
At that point I think it's pretty competitive with "go get". In both cases users have to install one thing, then use it to get your thing.
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.)
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.
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.
At that point I think it's pretty competitive with "go get". In both cases users have to install one thing, then use it to get your thing.
Haven't seen an internal rust tool yet.