Hacker News Reader

Comment by fatih-erikli | Hacker News Reader

I wouldn't recommend. If a dev environment needs such containers you probably work in crap

No, I simply do not want my workstation to be littered with dev dependencies that are used on a single project, or have to install nvm, rvm, asdf, to manage conflicting language runtimes. Nor I want to use Nix, not my jam, sorry.

All I need is Emacs, and podman.

Or you juggle multiple projects that may not be on the same versions of everything. Or you sometimes need to git-bisect back to an older version of your project, which may have older dependencies including e.g. Ruby or Python or Node versions or uses a different and incompatible version of Cmake or whatever, and it's much nicer to have an isolated environment for that, scripted such that it's used automatically, than having to fiddle with the programs actually installed on your dev machine.

And it's nice to have all that work across an entire team, no "works on my machine" weirdness.

Maintainig containers will cost more than keeping the package.json or rubyjso whatsoever updated.

Also you need some hacky things to make vbox running on OSX so it becomes totally a "works on my machine".

> Maintainig containers will cost more than keeping the package.json or rubyjso whatsoever updated.

Fine. What about compilers? System libraries? PostgreSQL version & config? Does package.json manage your node version? Oh and we switched from npm to some hipster new thing a while back, and older package.json files of ours will fail to install properly with the new thing. Have fun git-bisecting.

> Also you need some hacky things to make vbox running on OSX so it becomes totally a "works on my machine".

Been doing this for like a decade and it's not much more than "brew install docker" and a line or two in your shell rc file. It used to be slightly worse because you had to manage docker-machine separately, but it's never been hard or complicated.

How do you install brew? You copy paste a line from a website?

Yeah, of course.

I'm more of a Nix guy for solving this particular issue, but even assuming you were right (I don't believe so), sometimes you do have to work on crap. And it's better if you have a more reproducible dev environment when doing it.

Working on crap and working in crap are different things.

Working in crap: doing someones elses work

Working on crap: doing some work on legacy

And what would you recommend?

Also, if you fail to see the value in this, then I'd ask what you would use:

- When you need to work on multiple products with different environments.

- When you want to temporarily spin up development environments on powerful machines for parts of your work and rest of the time develop locally?

- When you want to pass an identical environment to someone else and have it just work.

- When you need to work on multiple products with different environments.

You interact with APIs. You don't have to install a database or another daemon to your local computer.

- When you want to temporarily spin up development environments on powerful machines for parts of your work and rest of the time develop locally?

This has never happened.

- When you want to pass an identical environment to someone else and have it just work.

All the dev stacks has something like package.json

> You interact with APIs. You don't have to install a database or another daemon to your local computer.

How about the people writing the APIs?, or the ones writing the servers?, or the os, or database, etc?

> This has never happened

In your case, use a bit of imagination.

> All the dev stacks has something like package.json

That is a very broad statement and in my experience, no.

So when you introduce or change a dependency to your project that affects what your dev environment must look like, how do you tie that change in with the main changes and make it available and consistent across all of your devs?

Email them? "Hey, everybody should upgrade to OpenCV version 4.1.5"? Garbage.

Devs interact with APIs, not OS-level libraries. If you do scientific research, you probably use python notebook or sth like that. If you need that OS-level solution to be integrated in your dev environment, you put them to Lambda or some other amazon instance, or a dedicated server.

Who makes the code that powers the APIs?! Who writes the OS-level libraries? What about people that write software for automotive, IoT, robotics, machinery? Is it your understanding that python notebooks never need to call out to OS-level libraries? (what is conda for then??)

Web developers always just assume the entire world is other web developers, and confidently dispense advice without any caveat re. its limited purview. The world is bigger than python notebooks and shitty ruby apps.

Well we are on web.

Reply on news.ycombinator.com