Hacker News Reader

Comment by physicsgraph | Hacker News Reader

A few years ago I set a goal to minimize the number of applications installed bare-metal on my laptop. Everything is containerized, just as the blog describes. There is some initial overhead, and some extra work associated with maintaining the infrastructure, but overall I can report improved reproducibility (due to an isolated and static environment per app).

I use a bash alias for each common application. For example, "jup" launches a jupyter notebook. I have a container with the Python package "Black" which runs using a git hook to clean up my code prior to commits.

View on HN

>For example, "jup" launches a jupyter notebook.

Would you be willing to share what you do with Jupyter notebooks, your workflow, how you collaborate with your team, your frustrations?

That just seems insane to be running black inside a container. Why dont you just configure your environment properly?

Serious question: Why do you believe that to be insane? The Dockerfile for a simple application such as black must be very short (probably 3-4 lines), the alias is probably quite short and the container overhead time is minimal for native docker (the story might be different for things like docker mac).

On the other hand, you get some benefits from installing black through docker rather than through the system package manager: is is completely isolated from the host and the only way to break black is to update it, changing anything in the host will not break your black install.

I am not sure either what you mean by "just configure your environment properly", but I am going to assume you mean installing black under a virtual env or equivalent? Then it is also annoying for different reasons: you must reinstall it once for each project, updating python to a new (major) version breaks your formatter, you cannot move the env around, to name the ones that come on top of my head.

> you must reinstall it once for each project

You can install it either in a venv outside of all projects or even "pip install --user black".

> updating python to a new (major) version breaks your formatter

Uninstalling the old version breaks the formatter. Installing a new one does not. Either way, with asdf, pyenv, and others you can keep all relevant version around.

> you cannot move the env around

Sure you can. Use "--relocatable"

I agree docker may be nicer if you're not working day to day in python... but in that case black is not a great example. You probably want to have a specific version bound to the project so everyone uses it (including the ci platform).

Did not know about --relocatable, thanks for the tip!

> But in that case black is not a great example. You probably want to have a specific version bound to the project so everyone uses it (including the ci platform).

That's what I do in my open source work, the CI will run the formatter and commit the result back in tree so it forces everyone on one version. At work this is handled by the developer tools' team.

> Uninstalling the old version breaks the formatter. Installing a new one does not. Either way, with asdf, pyenv, and others you can keep all relevant version around.

Yes but at some point you are basically making ad-hoc containers right? So why not use the generic one?

But can you still trigger the containerized Black from VS Code?

Yes. Only caveat is depending on how it's invoked you might need some --volume tweaking in your alias. If it's just being sent stdin then there shouldn't be any problem. Mounting whole project is probably best anyway for it to find tox.ini or whatever other config files needed. Also make sure the image doesn't contain any excessive output that uncontainerized black doesn't print.

This requires you to give your normal user the ability to execute stuff via docker. This means that given the ability to execute code as the user, an attacker can trivially gain root access.

There are many ways of running containers as a normal user:

https://docs.docker.com/engine/security/rootless/

https://github.com/containers/podman#rootless

I think in this context that's not a real concern, as on most laptop the human user has root equivalent permissions anyway (via sudo). In addition, Docker supports user namespaces, allowing you to have root in container being mapped to a non root user.

> On the other hand, you get some benefits from installing black through docker rather than through the system package manager: is is completely isolated from the host and the only way to break black is to update it, changing anything in the host will not break your black install.

Why would a system package, packaged by experienced maintainers, randomly break?

That just seems insane to be running black on any old system python. Why don't you just wrap it in a proper dockerfile?

Using that pattern, can you still easily run Black automatically on file save in IntelliJ or similar?

There were a few configuration steps the last time I configured regular black in IntelliJ, but the documentation wasn't too bad to follow.

Reply on news.ycombinator.com