[takeda]

With python you then use wheels + virtualenv, for Ruby you can use bundler. Each language has this issue solved.

Using containers is essentially:

- uh, I have problem with these dependencies, dealing with RPMs is such a nightmare, I need to generate OS specific packages and there might be conflicts with existing packages that are used by the system...

- oh I know, let just bundle our app with the entire OS!

[Apaec]

You could also use nix to handle all languages dependencies(including OS packages) and avoid the complexity of handling disparate package managers.

[closeparen]

Languages have the issue solved until your library is just bindings to a C shared library, in which case you also need the appropriate OS package.

[aldanor]

You build this shared library as a relocatable conda package and add an explicit dependency in your Python (conda) package / problem solved.

[raesene9]

I'd suggest that if containers end up looking like "the entire OS" then that misses a lot of the benefit of containers.

A container image should be "the bare minimum that allows the application to run".

[takeda]

Yes, I do agree with that.

If they are minimalistic and hold the app then this makes sense and then containers are essentially an unified packaging format that is accepted on "serverless" public cloud. This provides a value because you can then easily run your application on multiple providers where it is cheaper at given time.

I'm thinking that in the future your IDE could just compile your project into a single file that you then upload it anywhere and just run.

But the docker was promoted as something different with the union fs, nating etc. That works fine for development but it's a bit problematic operationalizing it.