logoalt Hacker News

Show HN: Home Maker: Declare Your Dev Tools in a Makefile

60 pointsby sthottingallast Sunday at 6:56 AM36 commentsview on HN

A developer's machine accumulates tools fast. A Rust CLI you compiled last year, a Python formatter installed via `uv`, a language server pulled from npm, a terminal emulator from a curl script, a Go binary built from source. Each came from a different package manager, each with its own install incantation you half-remember.

I wanted a way to declare what I need without adopting a complex system like Nix or Ansible just for a single laptop. The result was a plain old Makefile.

I wrote a short post on using Make (along with a tiny bash script and fzf) to create a searchable, single-command registry for all your local dev tools. It’s not a new framework or a heavy tool—just a simple way to organize the package managers we already use.

If you're tired of losing track of your local environment, you might find it useful.


Comments

bargainbintoday at 4:53 AM

If you haven’t tried it, I highly recommend Mise. It manages everything at the user level so it’s not as “all encompassing” as Nix and is readily compatible with immutable distros.

https://mise.jdx.dev/

Your solution is akin to putting your dotfiles in the code repo, which is going to cause issues with languages with poor version compatibility (such as node and python) when switching between old projects.

Also, bold of you to assume developers know make and bash just because they’re using Linux!

show 4 replies
sudonemtoday at 10:49 AM

My approach might be an outlier, but I’ll share since it’s a bit more platform agnostic.

I do almost all of it work in the terminal, so I had already been using chezmoi to manage my dotfiles for a few years. Eventually I added an Ansible bootstrapping playbook that runs whenever I setup a new environment to install and configure whatever I like.

I’m already living & breathing Ansible most days so it wasn’t a heavy lift, but it’s a pretty flexible approach that doesn’t bind me to any specific type of package manager or distro.

redohtoday at 10:25 AM

The fzf integration is a really nice touch here. Half the battle with dev tool management isn't installing things, it's remembering what you installed and how six months later. I know everyone's going to recommend Nix (and they already have), but there's something to be said for a solution where the entire logic fits in your head on first read. I've had a similar Makefile-based setup for years and the biggest win is onboarding new team members who can just read the targets and immediately know what's available.

loveparadetoday at 8:13 AM

Or just use nix with home manager. Battle tested, lots of built-in functionality, works perfectly. Author claims the learning curve for it is weeks, but I had my setup up and running in a 1-2 hours at most and have been super happy with it.

show 1 reply
ekropotintoday at 4:45 AM

I think you are re-inventing the wheel https://github.com/nix-community/home-manager

show 2 replies
duskdozertoday at 9:43 AM

I've ended up using a pseudo-make bash script with a helper that runs functions only once, mainly because I find adding new stuff to a makefile more annoying, and less intuitive and readable. Haven't come up with something easier so far

fertoday at 9:27 AM

There's already a bunch of comments about Nix, so I don't want to repeat them, but really Nix is less complex than a handcrafted series of Makefiles, and significantly more versatile.

With home-manager I have the same packages, same versions, same configuration, across macOS, NixOS, Amazon Linux, Debian/Ubuntu... That made me completely abandon ansible to manage my homelab/vms.

Also adding flake.nix+direnv on a per project basis is just magical; I don't want to think how much time I would have wasted otherwise battling library versioning, linking failures, etc.

landdatetoday at 8:09 AM

Alternatively, you can use the guix package manager. See here: https://guix.gnu.org/

Configuration is in scheme (guile) so that may be a turn off though.

theowaway213456today at 4:46 AM

Five years ago, I would've loved this. I love the simplicity and power of good old Make. And I obsess over my workstation's configuration. I used to have a massive bash script I would use to reprovision my workstation after every clean upgrade of Ubuntu.

But these days, I just tell codex to install things for me. I basically use it as a universal package manager. It's more reliable honestly than trying to keep up to date with "what's the current recommended way to install this package?"

I also have it keep a list of packages I have installed, which is synced to GitHub every time the list changes.

show 3 replies
rekadotoday at 8:09 AM

I use a Guix manifest for every project, which describes what dev tools and dependencies I want. When I enter a directory the shell automatically evaluates the manifest and all my tools are ready.

With tooling for deployment I prefer to heed an adaptation of Greenspun's Tenth Rule. Neither Guix nor Nix are really all that "complex" from a user's perspective.

0xbadcafebeetoday at 6:50 AM

I codify all my AI install/setup/running junk (https://codeberg.org/mutablecc/ai-agent-coding) with Makefiles. You can make DRY Makefiles real easy, reuse them, override settings, without the fancy stuff in the author's post. The more you build up a reusable Makefile, the easier everything gets. But at the same time: don't be afraid to write a one-off, three-line, do-almost-nothing Makefile. If it's so simple it seems stupid, it's probably just right.

tpoachertoday at 5:54 AM

I have something somewhat similar here: https://git.sr.ht/~tpapastylianou/misc-updater

The main difference is I initially only needed a mechanism to check if my "Manually-Installed or Source -Compiled" (MISC) packages have updates, but now it also supports install/upgrading too.

In other words, things I am forced to do by hand outside of a package manager, I now only do by hand once, save it as an 'install' script, and then incorporate it into this system for future use and to check for updates. Pretty happy with it.

stevekemptoday at 7:38 AM

I like the way that golang supports the use of tools in the go.mod file.

Something like:

     go get -tool github.com/golangci/golangci-lint/cmd/[email protected]
And then you can list tools :

     go list -f '{{.Tool}}' all
ANd run them:

     go tool staticcheck ./...
hantusktoday at 7:41 AM

I can recommend Pixi for this. https://pixi.prefix.dev/latest/

pixi init && pixi add wget

And youre ready to go, everything confined to the venv within the directory

tmaricetoday at 6:16 AM

I’ve been using devenv.sh for the last year for this, and never been happier.

axegon_today at 8:14 AM

I used to do that but there are a few catches. As much as I brush off people who use any OS other than Linux, there is a time when you will have to do something on another operating system. A lesson I learned the hard way: Make on Windows sucks royally. While I agree with the general idea and I also tend to be conservative about new technologies (even more so with all the slop-coding lately), just[1] is now a very mature and well thought out alternative.

[1] https://github.com/casey/just

esafaktoday at 4:52 AM

you can declare tools and tasks with http://mise.jdx.dev/

rheakapoortoday at 6:17 AM

[dead]

jellyfishbraintoday at 8:22 AM

[dead]

weiyong1024today at 6:48 AM

[dead]