3 ms·

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

mixedCase 4y ago
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.
- fatih-erikli 4y ago
  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
sph 4y ago
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.
- deleted 4y ago
  [deleted]
adriancr 4y ago
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.
- fatih-erikli 4y ago
  - 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
  - adriancr 4y ago
    > 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.
yamtaddle 4y ago
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.
- fatih-erikli 4y ago
  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".
  - yamtaddle 4y ago
    > 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.
    - fatih-erikli 4y ago
      How do you install brew? You copy paste a line from a website?
      - yamtaddle 4y ago
sebastos 4y ago
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.
- fatih-erikli 4y ago
  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.
  - sebastos 4y ago
    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.
    - fatih-erikli 4y ago
      Well we are on web.

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.

fatih-erikli 4y ago
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

sph 4y ago

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.

deleted 4y ago
[deleted]

adriancr 4y ago

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.

fatih-erikli 4y ago
- 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
- adriancr 4y ago
  > 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.

yamtaddle 4y ago

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.

fatih-erikli 4y ago
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".
- yamtaddle 4y ago
  > 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.
  - fatih-erikli 4y ago
    How do you install brew? You copy paste a line from a website?
    - yamtaddle 4y ago

sebastos 4y ago

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.

fatih-erikli 4y ago
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.
- sebastos 4y ago
  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.
  - fatih-erikli 4y ago
    Well we are on web.