Why some People prefer 1 to 2? I think 2 is more “production friendly” and universal across other languages and stacks (same approach used for java js ruby etc)
Why some People prefer 1 to 2? I think 2 is more “production friendly” and universal across other languages and stacks (same approach used for java js ruby etc)
Publish a module as a wheel if you want to be able to use pip to install it in your servers, or anywhere really.
Once you've built out your virtual environment you can build your docker image and push it to a registry.
Your helm chart should include references to docker images that are getting deployed to a kubernetes cluster, among other entities that need to be built out for your app to work.
Those are all different layers of the deployment, independent of each other.
If someone prefers 1 over 2 (or viceversa), they don't understand what they think they know.
So if you dont have modules that used across apps, then you dont need to package and publish wheel?
or if your modules are already vendored in your main application module (monorepo) then no need to package app as a wheel?
I would build it once for whatever required architectures are needed, build wheels for them, amd use those for packaging up the final apps that need deploying (through docker, k8s, whatever).
For internal use, where you can just pretend everything other than Debian based systems don't exist, it's ok, but I definitely see the value of docker, even though I like Snap a lot more.
I'm surprised nobody has ever made a "distro" where all the packages had a thin python wrapper and installed from a private Pip repository, so you could package your whole app and all dependencies with it.