HN Explorer

Show HN: Mkdevenv – managing dev environments with Makefiles and Containerfiles (github.com)

2 points by sedboyz ↗ HN
I created this repo to standardize the approach I'm currently using to isolate my development environments, which now allows me to integrate mkdevenv into other projects of mine.

It's primarily designed to integrate with GNU Emacs but should also work fine with other editors. While I'm aware of alternatives, I'm particularly inclined toward the fundamentals and the isolation that containers offer. (I'm currently writing a blog post on it, though I still need to give Nix/Guix a fair try as well).

3 comments

[ 6.1 ms ] story [ 16.7 ms ] thread
verdverm
fwiw, we are replacing Make + Dockerfile with just Dagger

- real CLI experience (with args & flags) rather than make shenanigans that arise at scale

- fully containerized for both dev & ci, works the same locally as in ci

- awesome CLI & Web UI logs / traces

- write in the language of your choice, growing ecosystem of modules (like GHA), real reusability in container based systems

sedboyz
> - fully containerized for both dev & ci, works the same locally as in ci

That's nice. I heard about Dagger a while ago. I think it would be a bit overkill for my use case, but I definitely need to check it since I didn't include it in my search phase / blog post draft.

I came across many scalable/production-ready tools, but I ended up deciding to go with this more fundamental approach since my projects aren't that complex/large. (And many of these tools prioritize reproducibility over isolation, which is fair, but not quite what I was looking for). That said, I still plan to try many of them anyway hehe

verdverm
I really like Dagger, definitely recommend adding it to your evaluation candidates. It consolidates a lot of tools and processes into one. We started with replacing Dockerfiles, but now we are also replacing Make. Dagger has made it incredibly easy to iterate and expand. For example, it was a breeze to add in several security scanning tools as we evaluate what we want to purchase. I didn't have to change our CI at all, just write a function per tool. The reason is that I have an internal struct in our Go that holds onto the information during running. It includes the source pre/post build and various stages of containers (base, building, runtime). I can then pass this struct to a function and it can decide what it operates on. Best part is I don't have to tell it to build ahead of time. Dagger is lazy and will determine the dependencies (kind of like make, but better) and perform the required precursor steps when needed.

The Dagger team is also incredibly helpful and responsive