Desktop/local usage, especially for non technical users or people working in environments where they can’t install docker (eg locked down corporate machine). There isn’t a great way to pass around a single executable or installer for a Python app. There’s pyinstaller, but it’s finicky and doesn’t quite work cross platform (you have to build the executable on the target OS).

On the other hand, OP’s setup makes it very easy to publish packages. So you can create a tarball and have a user pip install that, then run your app with a simple CLI. Or publish to pypi if you want it public. The downside is you assume the user has the right version of Python and knows how to switch versions if need be and all the weirdness that comes with that. But for web apps, packaging your app also makes it easy to wrap in a simple dockerfile that basically just installs the package and then runs it.

If you can't run docker, you're just as likely not to be able to run arbitrary executables.

In every modern corporate environment I've been in, you either have the ability to run whatever on your box, or it is locked down tight.

Yes, but if you sign the executable with an acceptable certificate (the company’s cert or some other trusted CA), you can install an arbitrary executable usually. Docker would typically be blacklisted, however. In most corporate IT environments, it’s much easier to get a small, focused executable white listed or code signed than to get something with such a huge attack area as docker approved for regular, non-technical users.

> There isn’t a great way to pass around a single executable or installer for a Python app.

Have you tried Nuitka or mypyc? (Haven't tried them myself but I've heard very good things about Nuitka.)

Also Briefcase: https://beeware.org/project/projects/tools/briefcase/. "Convert a Python project into a standalone native application."

Personally I have not. I have only had one particularly weird use case where I really needed to deliver a Python executable alongside an Electron app, and made it work with Pyinstaller. We’re actually reworking things to use Pyodide to compile the Python to WASM so we don’t have to deliver any separate Python code at all. It’s a real Rube Goldberg machine of an application, but we had a lot of weird constraints we had to meet (eg, we couldn’t use sockets to communicate between Python and Node, so had to package the Python as an executable). It works beautifully but it was a mess to get running.

Docker was made for development and testing of code, not production. It has been co-opted for production with good success. It seems fine to do it for hobbyist projects, but still feels dirty in a commercial setting.

The largest internet services on the planet were using LXC containers for production ops before you ever heard of the term 'docker'. In its earliest iterations it was easier to push a container to production than to run it on your laptop.

> using LXC containers for production

which isn't docker.

From what I recall, spotify were the first company with a large footprint to use docker. However for some reason they skipped VMs and went screaming into docker when it was _very_ new. Personally that seemed like a mistake, but you know, each to their own.

If you're wanting to get into a bun fight about containers, then IBM 360 and JCL has some time for you.

I'm using docker in commercial environments for years and cannot complain... But I don't distribute software, which is where the problem is probably more visible.

If we stopped using software in prod because it feels "dirty" we would not be using computers at all.

Why?

Why what?