7 ms·

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.

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.

deleted 6y ago
[deleted]
qmmmur 6y ago
That just seems insane to be running black inside a container. Why dont you just configure your environment properly?
- antoinealb 6y ago
  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.
  - viraptor 6y ago
    > 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).
    - antoinealb 6y ago
      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?
  - visarga 6y ago
    But can you still trigger the containerized Black from VS Code?
    - Too 6y ago
      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.
  - 6y ago
- hansvm 6y ago
  That just seems insane to be running black on any old system python. Why don't you just wrap it in a proper dockerfile?
t-writescode 6y ago
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.
Jugurtha 6y ago
>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?

deleted 6y ago

[deleted]

qmmmur 6y ago

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

antoinealb 6y ago
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.
- viraptor 6y ago
  > 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).
  - antoinealb 6y ago
    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?
- visarga 6y ago
  But can you still trigger the containerized Black from VS Code?
  - Too 6y ago
    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.
- 6y ago
hansvm 6y ago
That just seems insane to be running black on any old system python. Why don't you just wrap it in a proper dockerfile?

t-writescode 6y ago

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.

Jugurtha 6y ago

>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?