Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VSCode, Dev Containers and Docker

blog.feabhas.com

Post reply on HN
Print view View original

211–220 of 234 posts

Re: VSCode, Dev Containers and Docker

#211

Post by collyw »

rusticpenn wrote: post #177
scruple wrote: post #176

I'm not quite sure that I understand the advantages of doing development work inside of the container. What am I missing?

There are many advantages of containerized development. One example would be the protection of root environment from version pollution. My team uses and supports 3 versions of a framework, how do I test and develop in all of them without one environment affecting the other?

Why would you be doing development as root?

Personally I would use virtualenvs with Python to solve that problem you described.

Re: VSCode, Dev Containers and Docker

#212

Post by domano »

collyw wrote: post #211
rusticpenn wrote: post #177

Earlier quoted context omitted.

There are many advantages of containerized development. One example would be the protection of root environment from version pollution. My team uses and supports 3 versions of a framework, how do I test and develop in all of them without one environment affecting the other?

Why would you be doing development as root? Personally I would use virtualenvs with Python to solve that problem you described.

I think root refers to the main system environment, not the privileged user.

Re: VSCode, Dev Containers and Docker

#213

Post by m_mueller »

collyw wrote: post #211
rusticpenn wrote: post #177

Earlier quoted context omitted.

There are many advantages of containerized development. One example would be the protection of root environment from version pollution. My team uses and supports 3 versions of a framework, how do I test and develop in all of them without one environment affecting the other?

Why would you be doing development as root? Personally I would use virtualenvs with Python to solve that problem you described.

there's still system level packages that you might need, which may come into version conflicts among each other.

note: me too I default to virtualenv for local development, however there are usecases where this becomes insufficient.

Re: VSCode, Dev Containers and Docker

#214

Post by collyw »

kkapelon wrote: post #27
misiti3780 wrote: post #17

Earlier quoted context omitted.

for python, why cant you use use virtualenv with pyenv?

Because it is a Python specific thing. Docker works with all programming languages and that's it. If you are full stack or work with multiple programming languages there is no need to learn the "equivalent" of virtualenv everywhere else. Also with docker there is no setup/installation involved. You just pull the image and that is it. Also virtualenv requires that you already have pip/python installed. Docker requires…

I think every programming language that I have used has had something equivalent.

Re: VSCode, Dev Containers and Docker

#215

Post by collyw »

dhruvrrp wrote: post #22

Slightly off-topic, it really irks me when people take about reproducible builds/environments while using docker, while having something along the lines of apt-get update/pip install in their dockerfile. Like that completely destroys the reproducibility of your container!

Whats the correct way to get libraries into your docker container? We have plenty of apt-get / pip calls in the dockerfiles at my work (set up by someone else).

Re: VSCode, Dev Containers and Docker

#217

Post by CrazyPyroLinux »

shadowgovt wrote: post #188
Shicholas wrote: post #171

Earlier quoted context omitted.

you can still have a shared base Image for your teammates, then use that base image to create a new image just for your .vimrc etc.

I meant more that by modern standards, vim/gcc/gdb/make is a very labor-intensive toolchain to write applications with. "Doesn't scale" in the sense of "other developers are pretty unwilling to learn that chain of they didn't grow up with it."

> "other developers are pretty unwilling to learn that chain of they didn't grow up with it."

Funny, I've been running into this problem while trying to switch people to docker. Maybe we're all a bit guilty of this in our own way.

Re: VSCode, Dev Containers and Docker

#218

Post by panzerboy »

collyw wrote: post #210
carlosf wrote: post #129

Earlier quoted context omitted.

It actually makes your workflow more powerful as you can package it in a container and other devs can start using it in no time.

I have never managed to get a step through debugger working with Pycharm. I know it's possible, but things like this are why devs won't be able to "start using it in no time". Docker solves one set of problems and introduces others.

Yeah, unfortunately the JetBrains IDEs don't really work with this workflow yet. I'm hoping one day they will ...

Re: VSCode, Dev Containers and Docker

#219

Post by falcolas »

marcus_holmes wrote: post #200
falcolas wrote: post #142

Earlier quoted context omitted.

> So why do we want this? Just yesterday, I ran into an issue where a set of node unit tests were failing. My college and I were both getting failures, but different failures. The reason was: Different versions of Chrome, and thus different versions of the chrome integration plugin. Given that we have effectively no control over Chrome's auto-updates, we'll never have truly identical development environments. A conta…

But your customers still have widely varying versions of Chrome. So while your test might work, your code is still broken. Or did I misunderstand?

It's purely a test fixture setup that's failing because of a need for lockstep Chrome and the Chrome test fixture versions in Node. So, the code isn't broken for customers, just the local testing story.

Re: VSCode, Dev Containers and Docker

#220

Post by kkapelon »

collyw wrote: post #214
kkapelon wrote: post #27

Earlier quoted context omitted.

Because it is a Python specific thing. Docker works with all programming languages and that's it. If you are full stack or work with multiple programming languages there is no need to learn the "equivalent" of virtualenv everywhere else. Also with docker there is no setup/installation involved. You just pull the image and that is it. Also virtualenv requires that you already have pip/python installed. Docker requires…

I think every programming language that I have used has had something equivalent.

Let's assume that this is true (I don't think that languages like C/C++ have this but I may be wrong).

If I use 4 programming languages why learn 4 tools instead of one (Docker)?

Post reply on HN