It's great to see movement in this space. The main problem in my experience is github api and throttling. It's really hard to download 40 binaries while building an image for CI/CD. Binaries themselves are CDNed, but github apis to find them are easily throttled, especially behind NAT.
Need to have some caching mechanism avoid this. Eget seems currently abandoned, maybe gah can start looking stuff in a cache.
cool. please let me know when you post, I would like to read. I'm the author of dist if that wasn't clear. Also looking for feedback on the project should you find it useful.
eget duckdb/duckdb
2 candidates found (unsure architecture): please select manually
(1) duckdb_cli-osx-universal.zip
(2) libduckdb-osx-universal.zip
Enter selection number:
Afterwards it correctly unzips. Can use cmdline flag to match artifacts
`gah` fails:
gah install duckdb/duckdb
Fetching release info for: duckdb/duckdb [latest]
Found release: v1.1.3 Bugfix Release
Downloading:
Warning: output file name has no length
curl: option -o: is badly used here
(Using curl 8.4.0 on macOS)
`dist` also fails:
dist install duckdb/duckdb
• determining latest version
• version: 1.1.3
⨯ no matching asset found, score too low
⨯ closest matching: duckdb_cli-osx-universal.zip (34) (threshold: 40)
I thought that no one in right mind will use underscore in the binary name, but it seems that I had too much faith in humanity. Fixed:
gah install duckdb/duckdb
Fetching release info for: duckdb/duckdb [latest]
Found release: v1.1.3 Bugfix Release
Several download URLs were found which match your OS and arch. Please select one:
1) https://github.com/duckdb/duckdb/releases/download/v1.1.3/duckdb_cli-linux- amd64.zip
2) https://github.com/duckdb/duckdb/releases/download/v1.1.3/libduckdb-linux-amd64.zip
#? 1
Downloading: duckdb_cli-linux-amd64.zip
##################### 100,0%
Extracting: duckdb_cli-linux-amd64.zip
Installing: duckdb
Give a new name or keep 'duckdb'? (Leave empty to keep the same)
New name:
Installed: duckdb
Done!
--no-score-check didn't help, so i didn't include it.
Works with your fix.
I sent you an email to schedule a chat. Hope you don't mind. I'm very thankful for your work in this space. Will keep testing this in place of my eget workflows.
Some thoughts so far:
1. ability to pick my own dir or to default to .local/bin . Eg I love using eget from ansible to drop various useful binaries
2. Ability to override github url, so I could do my own token management/cache in a centralized way. This would fix the biggest downside of such tools in CI.
4. lazy mode. I have an ad-hoc script to lazily download various nice-to-have-but-heavy binaries into devcontainer on my team. Eg it's a bash script that checks if usql is in path, if it's not, it downloads a pinned version and runs it and passes args through. Given how fast most binaries are this is the only way to have all the binaries we need without wasting gigs of space of stuff that only 1 person on team may use.
Technically there's a config file and you can set the path, it's not been tested a lot on custom paths and I haven't documented it yet, but if you look at the source it'll show you how.
I'm working on a Distfile so be able to install multiple pinned versions at the same time, I'm also working on installing multiple binaries at the same time.
I think compiling go is something I'll stay away from. I think it would be better to encourage folks like mic92 to use goreleaser and publish static binaries.
It's great to collaborate on code in a P2P way. I think in the end, we also need a way to share binaries in a P2P manner using Git (so we can track history with the beloved Git). Maybe it's a good idea to integrate git-annex into this?
It's not that it doesn't work, it's that you lose information. normally a flag would be:
.Fl x
And an environment variable:
.Ev VARNAME
Instead of just saying "this text is bold", or just not marking it at all.
Does that matter? Maybe, maybe not. In theory at least "a list of all flags used and referenced in this document" and "list of all env vars references" would pretty useful. In practice so many manpages get this wrong that it just doesn't work half the time, so then it's no longer all that useful for the general case.
Unless AsciiDoc changed a lot since I last looked at it, it doesn't support anything like this.
The oddball reStructuredText also has a similar system of "roles" and "directives", but its syntax is kind of painful to use and IMO AsciiDoc is easier to read and write.
I'm not sure if avoiding Home Manager is the right choice for everyone, but it worked well for me.
Home Manager isn't necessary for declarative management of the user environment -- Nix flakes can do this, too. A long time ago, I kept a single `flake.nix` in my home directory describing the packages that each of my machines needed, and ran `nix profile install .#packages.<machine>` to install them into my user profile. By doing things this way, I learned a lot about writing flakes, and this transferred to other places I used Nix.
What this doesn't do that Home Manager does is dotfile management, but that's actually why I avoided HM originally. First, HM's approach is a bit clunky for my taste: each change to the configuration must be followed by running `home-manager switch` for the changes to take effect. I found this to slow down the edit-and-test loop when making changes to my shell config, etc. Second, the idea of doing all configuration in the same Nix language is cool, but most of the documentation found online about configuring, etc., `git`, will refer to the tool's usual method of configuration.
So instead, I made a quick Python script that manages package installation with Nix, and dotfile management with GNU Stow. The dotfiles and Nix configuration all go into the same git repository in my home directory, so they are tracked together. I've been using this approach to manage several machines for a few years now, and it's been more than sufficient for my needs.
In addition to that home-manager does not have have the same value NixOS modules have. You are mostly translating configs and not receiving big parts which are normally copied from the documentation for free.
Oh! The lack of (what I now know is) Home Manager is what made me drop Nix not long after trying it out briefly a while ago (well, several years now, maybe 2015-16). I really liked the sound of having all my config declarative and managed through Nix, but it's almost all in home - not everything even has system-wide config, and anyway it's easier to version control.
So that's just to say I think it at least warrants a mention, it's helpful for a beginner to be aware of, even if they don't use it (once informed they can decide for themselves if they need that piece or not).
Some people may enjoy going through an enormous learning curve to do configuration like that, but the benefits there are pretty abstract and personal, and the pressure to make the onboarding any easier is very low. It's partly because these kinds of users are willing to (a) suffer through a lot in the name of learning and feel good about having done that, and (b) read and write what appears to be a dozen book-length tomes of documentation, that it doesn't get any easier for beginners. I know because I was also one of them in 2015-16 or thereabouts.
Nix doesn't need any more home-manager tutorials, because it doesn't need any more small-time tinkerers. It would benefit more from becoming essential to a bunch of businesses who will become invested in making their own developer experience acceptable at scale, and who will have to improve Nix to that end.
Pretty soon a bunch of people are going to realise they actually do need the exact same version of every tool in every toolchain on every machine in a team, to make use of the transformative caching abilities of tools like Bazel and Buck2. And if that catches on, I would not be surprised to see an alternative Nix frontend configured in Starlark, like every other tool in that arena. There's already a buck2-nix that generates dhall under the hood.
I do sometimes think Linux could do with being single user, and retaining a separate no-login non-user ('roles'?) permission system for 'mail', 'cups', and the like.
As far as I'm aware multi-user (as in human login users) Linux systems are almost entirely - literally - academic. Supporting it does leave some warts and complexity to be experienced by the majority single-user system users.
Im a beginner and am working through getting Nix + Home Manager + Darwin working. Currently I am only setting it up on a MacOS vm's so I can nuke everything, but the end goal is to install it on my host system and manage everything I can with it, including home-brew.
Yes, home-manager + darwin is added complexity that is making this harder for me; when I am encountering problems I am not always clear on where in the three systems it lies. But I probably wouldn't be journeying into Nix if it wasn't for home-manager + darwin; what I want is managing my workstation and setting up ad-hoc development environments, not configure servers.
I'm a beginner, and I set up my system with Home Manager and on MacOS Nix Darwin. It works extremely well, and both Home Manager & Nix Darwin are quite well-documented. The hardest part was figuring out the different arguments to various Nix functions (sometimes I wished Nix had types).
I started with just Nix-Shell in WSL with Home Manager. Then I have kept adapting that file for my Linux, OS X, and other needs. I didn't touch NixOS at all until years later. I'm really, really glad I started with Home Manager. It delivered value immediately, and I was instantly sold on the value proposition of a declarative file to manage dependencies with other associated benefits from the Nix world.
Quite the contrary. Home-manager is literally the only thing that's worth using Nix. Anything beyond that is far too esoteric, unsupported, non backward compatible and continuously broken.
My dotfiles managed by nix(-darwin) and home-manager breaks every time I update my pins, and I find myself having to bisect which commit introduced the issues. Given that, I just don't see how that would scale to a full OS, let alone to a team at work. 1000% better simpler with understandable Dockerfile and Kubernetes YAML manifests, or with Ansible YAML. At least every folk can StackOverflow and ChatGPT it to a working state, and have it work for a considerable amount of time without further maintenance.
Unless I'm misunderstanding something, this is precisely why I don't use Home Manager. I've literally never had my NixOS setup break over the course of many years.
Ya their comment does not match up to my experience at all. When I update my lockfile it very rarely breaks and if it does I just roll back a commit and wait a day and it's usually fixed.
This is... sort of the point, too. Rolling back is insanely easy - and it's version controlled so even if something obnoxious happened you (should) know the exact commit that broke something as well.
In the very worst case, you update components individually until you find the offending one.
I've used both NixOS and nix-darwin for 2 years professionally now as daily drivers, and have had generally nothing but great success. I'm not fearing an OS update actively breaking my environment (which I can't say the same for macOS, as much as I am a fanboy of Apple).
Sorry for the harsh words but you don't have any idea what you are talking about.
Some examples: managing patches for applications is doable with NixOS. With overlays they survive updates and if they no longer apply, build fail before they can have production impact. Doing the same with docker is a nightmare and different for every dockerfile without a common interface around it.
Ansible takes the previous state of the system into account which is terrible if you want to manage it fully declarative. Worst case in NixOS you do a reboot and your config applies almost no matter the previous state.
And that you can leave something running without maintenance is naive and it will start to slowly rot.
I think there’s a consensus around a gap Witt respect to documentation, forums, porcelain, etc. in Nix world.
But with all due respect, asserting that everything outside of home manager is “not worth using” is fertilizer.
The fact that smart companies (TailScale and Shopify come to mind, but there are zillions) are willing to cope with those (obnoxious) gaps is very, very strong evidence that there’s a lot worth using.
git was considered too hard, inadequately documented, maliciously baroque for years before GitHub happened.
Nix solves a harder (and more important) problem in a similar way.
Debian documentation has usually the same gap but there are many resources out there how to get things done but not necessarily the way debian intended which can break things on updates or name them unnecessarily hard.
The display and keyboard would be fun to have where I interact with the ras pi directly; I don't need to attach another sbc to a ras pi of course; but where is there such a neat display and keyboard that I could get for a pi? I have several rasp pi, I wish they had an inexpensive display and keyboard like this one. I could use it for commands on the shell.
But it's mostly to play with.
That's just a great form factor! In such a situation, I was thinking you could use the cpu to communicate with the ras pi somehow, ssh into it? It's just a neat form factor with that compact keyboard and display, using such little power.
By itself it's fun too, but I'm not going to do much assembly work, not doing anything that takes soldering. I'm just terrible at that kind of stuff. If I could buy a complete little computer like that, with some kind of storage maybe, it would be neat. I didn't understand how much effort it would take to get an actual working system that I could type on like the original poster.
reply