[chakspak]

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.

[unbanned]

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

[chakspak]

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.