Hacker News Reader

Comment by TekMol | Hacker News Reader

Are virtual environments still needed now that we have containers?

I just run everything in a container and never need a virtual environment. Am I missing out on anything?

For me it's the debug experience that is lacking when only using containers, I have some work arounds but they are still not good enough.

Can you give an example?

I don't experience any difference, whether I am inside a container or on the host os.

Can you debug in a container, eg VS code debugger with breakpoints and steps?

I have no experience with that as I use pudb for debugging, which I simply run inside the container.

Yea it is a supported use case. VS code remote extension can work with every container just like remote ssh development.

yes, devcontainers work very well. Full debugger. It's also possible to run the container in the cloud and still get a full local debugger.

I did have some issues with some projects and want to revisit this soon.

Not all Python users run containers, especially in the sciences. When you are teaching basics of data manipulation to people that have barely touched any programming language before, getting people to grok even virtual environments is not trivial.

To me, containers are simpler than virtual environments.

Just do "docker run --rm -it debian:11" and you are ready to go.

This is the version of containers where they are most useful - a clean, throwaway environment with exactly the one application or userspace you want to test inside it.

Unfortunately as a developer it's more fiddly than that.

You need to mount your code into it. Then if you try commit changes to your code, you're a different user, so the commit is now messed up. Also you lost your dotfiles, so none of your aliases or other shortcuts work when you're in the container. You might need to connect to other services which now need to run in their own containers, and then they all need to talk to each other. Before you know it there's a whole litany of commands you need to run and configuration files you need to put together just to get started in the morning. Imo using containers on development machines is a big step backwards for developer productivity.

Virtual environment is just... cd in the directory. Run magic incantation to set that directory as the canonical one for your current shell. The end. IDEs will pick it up automatically.

The Python virtual environment and package management experience is still worse than pretty much any other programming language, but for me it's far and away better than using containers on a development machine.

You make it sound like you have to edit your code inside the container.

I don't do that. I edit it on the host OS.

I just run the code inside the container.

Do you have to mount the location of the code as a volume in the container also?

I use containers regularly but adding them to a development workflow for a standalone python application I could just as easily run directly without having the additional complexity of navigating container boundaries always mystifies me.

Yes, I have one terminal window in which I run / use the code. I start it like this:

docker run --rm -it -v $(pwd):/some/where debian:11

Most of the time I don't use plain Debian, but an image based on Debian which I have peppered with some convenience stuff.

> I just run everything in a container and never need a virtual environment. Am I missing out on anything?

I don't think it is practical for compute heavy scientific visualization. Setting up GUI with docker was a nightmare for me. There is also some overhead for CPU/GPU heavy code.

At $WORK, I more or less can only develop on a Windows machine. Getting Docker approval is needlessly painful. Until Docker and WSL are Microsoft standard tools, then yes, these solutions are required.

How is WSL not a Microsoft standard tool? What makes it different from Visual Studio or VSCode or whatever, which is also never going to be built into Windows? Why can you get Python installed but not WSL?

WSL is a full Linux/Ubuntu?

So you can install whatever you can apt-get/wget into it?

I can see that being a problem in restricted environments.

For a software developer, who can run any software they want (because they need to be able to run the software they’re paid to work on), including software that could subvert all the restrictions anyway?

Clearly you are not familiar with corporate IT and "security" compliance.

I kinda am (though luckily not subject to it), and I find it laughable.

If that's really an issue, corporate IT can have an air gapped repo used for apt-get. I use purely air gapped systems at $WORK and it's not too bad.

I use both. Containers for server code, environments for scripting. Containerizing scripts is a bit excessive, especially if it's only going to run on your machine.

Reply on news.ycombinator.com