Kudos to you!
Show HN: Home Maker: Declare Your Dev Tools in a Makefile
41–50 of 71 posts
Re: Show HN: Home Maker: Declare Your Dev Tools in a Makefile
#42There'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 p…
Make is generic. Nix is not.
Before I even look at the actual code I already know that it is something I can use immediately on my existing system, no matter what that happens to be, right now, without changing anything else.
It doesn't matter how great nix is because it's not alpine or xubuntu or suse or freebsd or sco osr5 or solaris or cygwin, it's nix.
Even if you're only talking about nix the package manager, or nix the language, and not nix the os, it actually still applies because Make is everywhere and nix is not.
Even if this thing has bash-isms and gnumake-isms, I bet with minimal grief I can still use it on a Xenix system that doesn't even have a compiler (so no building nix) but does have ksh93 and make, even without leaning on the old versions of actual gnu make and bash that do exist.
Re: Show HN: Home Maker: Declare Your Dev Tools in a Makefile
#43> Docker/containers solve isolation, not tool installation. You do not want to run your editor, terminal, and CLI tools inside containers.
I'm not in agreement here. You can have a Dockerfile in which all tools get installed. You build it, and tag it with, let's say `proj-builder`.
Then you can run commands with a mounted volume like `docker run --volume $(pwd):/sources `. And alias it.
Re: Show HN: Home Maker: Declare Your Dev Tools in a Makefile
#44> Every developer on Linux already knows both.
I've been developing on Linux for over 10 years and I don't. It's like exiting vim: whenever I want to do anything beyond running a command or basic variable use, I have to go lookup how to do it online. Every time.
Re: Show HN: Home Maker: Declare Your Dev Tools in a Makefile
#45Re: Show HN: Home Maker: Declare Your Dev Tools in a Makefile
#46I'd recommend trying to get 1 package manager to handle all of it, like Brewfile [0]. > Docker/containers solve isolation, not tool installation. You do not want to run your editor, terminal, and CLI tools inside containers. I'm not in agreement here. You can have a Dockerfile in which all tools get installed. You build it, and tag it with, let's say `proj-builder`. Then you can run commands with a mounted volume lik…
Re: Show HN: Home Maker: Declare Your Dev Tools in a Makefile
#47There'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 p…
"This problem has already been solved in Canada. Just move to Canada." Make is generic. Nix is not. Before I even look at the actual code I already know that it is something I can use immediately on my existing system, no matter what that happens to be, right now, without changing anything else. It doesn't matter how great nix is because it's not alpine or xubuntu or suse or freebsd or sco osr5 or solaris or cygwin,…
Hard disagree on this one. It's a series of makefiles that depend on apt (or whatever pacman you choose), so for any heterogeneous environment it's going to constantly be uphill battle to keep working in terms of package naming, existence of dependencies, etc. You'd find yourself reinventing Ansible, but worse.
> It doesn't matter how great nix is because it's not alpine or xubuntu or suse or freebsd or sco osr5 or solaris or cygwin, it's nix.
Nix runs fine on most (all?) modern Linux distros, macOS, even WSL, and there are workarounds to make it run on BSD, though I admittedly haven't tested those.
> Even if this thing has bash-isms and gnumake-isms, I bet with minimal grief I can still use it on a Xenix system that doesn't even have a compiler (so no building nix) but does have ksh93 and make, even without leaning on the old versions of actual gnu make and bash that do exist.
Use it on Xenix (which last shipped in 1991) to do what? The package management was tarballs and compiling. Instead of reinventing Ansible, you'd be reinventing pkgsrc. Not sure what your point here is.
Re: Show HN: Home Maker: Declare Your Dev Tools in a Makefile
#48Earlier quoted context omitted.
Now with LLMs it's even easier. Writing nix code is hard, but reading it is straightforward because it's declarative, so you can easily review what an LLM produces. And it's not much code either, a simple home manager setup is maybe 100 lines total. 1. Install nix / determinate nix 2. Tell your favorite llm to set up https://github.com/nix-darwin/nix-darwin with home manager if you are on mac, or just home manager if…
Ah yeah I wouldn't count that as being a small learning curve because you haven't actually learnt anything. Valid approach though I guess.
Re: Show HN: Home Maker: Declare Your Dev Tools in a Makefile
#49Or 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.
This must be a different "just" from the just I'm used to! Weeks sounds way more accurate than 1-2 hours.
{ pkgs, ...}: {
home.packages = with pkgs; [ neovim lazygit ];
}Re: Show HN: Home Maker: Declare Your Dev Tools in a Makefile
#50I made something similar but with Ansible wrapped as an uv script. What I like about ansible is that it's higher level so I'm able to do complex modifications to my machine without having to write them myself and handle the errors myself because the community behind the tasks have already done it. The idempotency of ansible out of the box is also very nice.
Here is my ansible/uv-script project if someone is interested: https://camilo.matajira.com/?p=591