undefined | Better HN

0 pointspacala8y ago0 comments

That is a solid solution. As long as everyone in the ecosystem is on JVM, more power to you. If, for example, one needs to interface with some cutting edge DL modules written in Python, one needs something else. The transitive closure over "something else" is called "containerization".

PS. Maybe "EAR" also supports Python. But then I'd argue "EAR" is a "container".

0 comments

takeda8y ago

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!

Apaec8y ago

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

1 more reply

closeparen8y ago

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.

aldanor8y ago

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

raesene98y ago

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".

takeda8y ago

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.

j / k navigate · click thread line to collapse

0 comments

takeda8y ago

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

Using containers is essentially:

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

Apaec8y ago

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

1 more reply

closeparen8y ago

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.

aldanor8y ago

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

raesene98y ago

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".

takeda8y ago

Yes, I do agree with that.

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.

j / k navigate · click thread line to collapse