Earlier quoted context omitted.
If I need an image with a specific set of tools it's cumbersome to build a whole workflow to build, store and maintain these images. Having a service that can receive a custom list of Nix packages and returns an image that I can instantly use would be really, really, really nice.
That's what most users of nixery.dev (i.e. the public instance) do, afaict. Ad-hoc images for CI, and for debugging purposes.
Nixery – Docker images on the fly with Nix
51–60 of 90 posts
Re: Nixery – Docker images on the fly with Nix
#52Earlier quoted context omitted.
We recently adopted it at my company for managing local dev machines, project environments, and CI. It definitely has some warts, often the best documentation is “read the source code”, but man is it an awesome tool. I’ve switched all of my machines / servers over to it and I’ll never look back. Now I’m looking at my iPad and iPhone and wishing I could manage them through Nix too. I’d put it at a comparable difficult…
There's an experiment Nix fork of Temrux for Android, if you want to try on mobile. Good luck on an iPhone though.
Re: Nixery – Docker images on the fly with Nix
#53Earlier quoted context omitted.
We recently adopted it at my company for managing local dev machines, project environments, and CI. It definitely has some warts, often the best documentation is “read the source code”, but man is it an awesome tool. I’ve switched all of my machines / servers over to it and I’ll never look back. Now I’m looking at my iPad and iPhone and wishing I could manage them through Nix too. I’d put it at a comparable difficult…
How can one use Nix to manage project-specific dependencies that typically store Dotfiles in annoying locations like the home folder? I am aware of home-manager but am not sure how (or if) it would work for per-project dot file management.
It depends on what the dotfiles are for and how they're used.
Here's an example of a problematic one: AWS configs. You can theoretically override the default location of these files with environment variables, but a lot of tooling doesn't respect this and will break as a result.
I often deal with a large number of AWS accounts, so my solution is to have one main way for populating AWS config files that lives outside of projects, and then, because I have a rubric for account/role assignment naming, I can select the correct account/role for each project, and I can even have projects that switch them based on specific code/deployments.
Re: Nixery – Docker images on the fly with Nix
#54Oh great! More indirection. Now when I want to deploy my web app I can check my private nixery.dev deployment is properly configured in Nix to build my Docker images so I can deploy my containers to the cloud so someone can access me Rest API. And the cost of guaranteeing builds will probably work? Running your own nixery service, learning Nix, and learning Docker. I would love someone to do a cost-benefit analysis o…
Do you actually use nix and have an experience to share?
I want to like Nix, I made my primary computer NixOS, but it’s just so much complexity. For small dev environments I kind of get it - I might still use it to spin up a Haskell env - but when the total Nix lines of code > 10k for a project then have fun!
Re: Nixery – Docker images on the fly with Nix
#55I don’t know if it’s just because I hopped on the bandwagon in the past few months, but it really is starting to feel like Nix is gaining momentum. You can use it on Mac, WSL, Ubuntu multiuser, Docker, in an nspawn container, or through NixOS on a drive. You can build a livecd iso or a Raspberry Pi image from the same flake that you use for everything else. I work in embedded with Yocto every day, and I can’t help bu…
I was afraid of Nix before I adopted it based on what I've read. Now that I've taken the leap, there is no going back. Other operating systems are crude dinosaurs in comparison. Once you get past the learning curve and the initial setup (which can be steep), your system will be far more stable and easy to maintain than anything out there. Declarative OS builds are the future, whether it's Nix or something else.
Re: Nixery – Docker images on the fly with Nix
#56Earlier quoted context omitted.
I was afraid of Nix before I adopted it based on what I've read. Now that I've taken the leap, there is no going back. Other operating systems are crude dinosaurs in comparison. Once you get past the learning curve and the initial setup (which can be steep), your system will be far more stable and easy to maintain than anything out there. Declarative OS builds are the future, whether it's Nix or something else.
Okay, sorry to hijack, but I keep trying it, and keep getting stuck. Most recently, how do I install a Rust binary from Github? They have a releases page, or I can just do a cargo build. Either way, I would just drop the resulting binary in /usr/bin and it's done. With Nix... I'm totally stumped. Do I have to package it myself somehow?
The good news is once you learn how, it's basically trivial with crate2nix[0], which can autogenerate nix derivations from rust crates
Re: Nixery – Docker images on the fly with Nix
#57Earlier quoted context omitted.
I love nix, but you're a lot more optimistic and forgiving of its cons than I am :D To be clear, I've not used NixOS and it might be a more reasonable experience. Nix package manager though is the most useful tool I have integrated into my dev-life and also the one I am most hesitant to recommend to anyone else. The UX of the whole thing still has a long way to go and the initial installation experience on Mac has be…
> and the initial installation experience on Mac has been all over the place quality-wise in recent years. In minor defense of this, Apple making the root read-only threw a pretty big wrench in things. There are a lot of little reasons (some understandable and some exasperating) it took so long to adjust, but all of them were exacerbated by the amount of new logistical complexity required (and the amount of experimen…
I understand the reasoning of avoiding this on Intel Macs, since there there are years of cached derivations which would become useless without hacks. However, Apple Silicon Macs are a clean slate and the transition would've been a good occasion to move the store to /opt/nix.
(I did suggest this in some places, but there didn't seem to be much interest in switching over, unless I missed something.)
By the way, this isn't only an issue with macOS. Nix also doesn't work on Fedora Silverblue because it uses read-only root and the Nix store path violates FHS.
Re: Nixery – Docker images on the fly with Nix
#58Earlier quoted context omitted.
I was afraid of Nix before I adopted it based on what I've read. Now that I've taken the leap, there is no going back. Other operating systems are crude dinosaurs in comparison. Once you get past the learning curve and the initial setup (which can be steep), your system will be far more stable and easy to maintain than anything out there. Declarative OS builds are the future, whether it's Nix or something else.
Okay, sorry to hijack, but I keep trying it, and keep getting stuck. Most recently, how do I install a Rust binary from Github? They have a releases page, or I can just do a cargo build. Either way, I would just drop the resulting binary in /usr/bin and it's done. With Nix... I'm totally stumped. Do I have to package it myself somehow?
Here is a more involved example of downloading a release and then extracting the binary from a .pkg file: https://gist.github.com/J-Swift/364a8b158bf0b603f6e784e454ca...
Here is a more simplified example: https://gist.github.com/mitchellh/c47e3333bb78f57836ba2aa806...
EDIT: to get the sha, unfortunately you have to perform some esoteric command line incantations: https://github.com/NixOS/nix/issues/1880#issuecomment-366615... and https://gist.github.com/boxofrox/d8a3080fbb03f84b7d7a31e102b...
Re: Nixery – Docker images on the fly with Nix
#59Earlier quoted context omitted.
> and the initial installation experience on Mac has been all over the place quality-wise in recent years. In minor defense of this, Apple making the root read-only threw a pretty big wrench in things. There are a lot of little reasons (some understandable and some exasperating) it took so long to adjust, but all of them were exacerbated by the amount of new logistical complexity required (and the amount of experimen…
For sure, that part is understandable and the current install is pretty simple since FDE avoids previous steps. But for a while it was _really_ difficult to find the needed info (had to read through Github issues and find specific comments embedded in extremely long threads)
There were some dumb (but common in informally-organized OSS...) reasons it malingered. Most of them are still problems (though a few have improved or are slowly moving towards it). A lot of the fixes entail investments in improving leverage of time spent on the installer. Better automated testing, more organizational structure/memory/accountability, etc.
But those issues wouldn't have been enough headwind to drag the situation out like it did if there was always one obvious straightforward politically-acceptable solution from day-1 that just needed to get implemented.
Re: Nixery – Docker images on the fly with Nix
#60Earlier quoted context omitted.
I was afraid of Nix before I adopted it based on what I've read. Now that I've taken the leap, there is no going back. Other operating systems are crude dinosaurs in comparison. Once you get past the learning curve and the initial setup (which can be steep), your system will be far more stable and easy to maintain than anything out there. Declarative OS builds are the future, whether it's Nix or something else.
Okay, sorry to hijack, but I keep trying it, and keep getting stuck. Most recently, how do I install a Rust binary from Github? They have a releases page, or I can just do a cargo build. Either way, I would just drop the resulting binary in /usr/bin and it's done. With Nix... I'm totally stumped. Do I have to package it myself somehow?
If you don't care about Nixpkgs conventions ("build phases", etc.) then you can use `runCommand` to run arbitrary bash code. It's a function which takes three arguments: a name for the output, a key/value mapping for the environment variables (plus a few some special names), and a string of bash code (usually written between ''two single quotes'').
with import {};
runCommand
"my-favourite-program" # A name for the output
{
# A key/value mapping of env vars
myVar = "myValue";
# The 'buildInputs' name is special: for each element 'x', the directory '${x}/bin'
# will be appended to the PATH env var
buildInputs = [ jq gcc ];
}
''
# This is a multi-line string containing arbitrary bash code.
# The output path will be provided via the env var $out so we
# just need to create a file or folder with that path
mkdir -p "$out/bin"
echo "$myVar" > "$out/bin/my-executable"
chmod +x "$out/bin/my-executable"
''
One complication is that (by default) the script will be run in a sandbox, with no network access. We should fetch anything it depends on up-front, using e.g. fetchurl, fetchGit, etc. Here's a more realistic example: with import {};
runCommand "foo"
{
release = fetchurl {
url = "http://example.com/foo/foo-1.0.zip";
hash = "sha256-iqZDwWkQA9XMTICEMCt5xDlmfmiIwzpeE3HJLbgbDXs=";
};
buildInputs = [ unzip ];
}
''
unzip "$release"
mkdir -p "$out/bin"
mv foo-1.0/binary "$out/bin/foo"
''