Tangential, has anybody replaced private container registries with a place to upload and download container tarballs?
Deploying Containers on NixOS: A Guide
51–60 of 60 posts
Re: Deploying Containers on NixOS: A Guide
#52I think it's great to document this, and some people are going to prefer working with containers no matter what. That said, personally I've moved away from it and these days I just use nixos modules and run all of the services on my home server directly on the host. You don't get the same isolation that you might get with proper containers, and that might be an issue for production machines, but I find the simplicity…
If you're after simplicity, it's hard to beat docker compose for self hosting stuff. I run NixOS on my laptop and routinely run into things that aren't yet packaged for NixOS, but I've yet to come across a project where I had to write my own dockerfile.
Personally I’ve always found working with docker to be pretty frustrating, especially dealing with docker compose. Most of what I run on my server is at least in nixpkgs already if not already a NixOS module, and I just find it less frustrating to write nix than to deal with Docker.
That said, I know nix pretty well at this point and I would probably have a different opinion if I hadn’t spent so much time learning nix.
Re: Deploying Containers on NixOS: A Guide
#53Earlier quoted context omitted.
If you're after simplicity, it's hard to beat docker compose for self hosting stuff. I run NixOS on my laptop and routinely run into things that aren't yet packaged for NixOS, but I've yet to come across a project where I had to write my own dockerfile.
Personally I’ve always found working with docker to be pretty frustrating, especially dealing with docker compose. Most of what I run on my server is at least in nixpkgs already if not already a NixOS module, and I just find it less frustrating to write nix than to deal with Docker. That said, I know nix pretty well at this point and I would probably have a different opinion if I hadn’t spent so much time learning ni…
> That said, I know nix pretty well at this point and I would probably have a different opinion if I hadn’t spent so much time learning nix.
Yeah, I'm in exactly the opposite boat—I've been using docker professionally and at home for 5+ years now and know it very well, while nix is still very new to me!
There's probably no way to objectively tell which one we'd have preferred if we started in the opposite order.
Re: Deploying Containers on NixOS: A Guide
#54Earlier quoted context omitted.
I think it's also an issue with the flexibility paradox. There isn't a good single way to package Python for Nix because before you even start there are several key questions which come up that most other distros can't even begin reasoning about: - Are we packaging just one Python package for Nix, or a thing and all its dependencies? - Is the package already on PyPI, and are we packaging the source from there, or is…
At the same time Nix implements python packaging particularly bad[1] when it does not have to. And that's on top of already insane state of python packaging. And poetry2nix becoming deprecated really bit me recently :/ Similar issues (minus insane packaging) is with Common Lisp packages, where there's annoying focus on compiling libraries into binaries (it would have been fine to have a bit of patching to provide thi…
I will say, there is one element of Nix's core design that makes almost all of these integrations considerably worse than they have to be, and that's the whole IFD fiasco— if it were possible to ingest an ecosystem-specific lockfile, run a build on it, and evaluate that result, then a lot of the drama and workarounds would melt away. This is sort of supported today, but it's basically banned from nixpkgs because of how the current implementation pauses evaluation any time it needs to run a build that evaluation is dependent upon... and it can only run one such blocking build at a time.
The new rust implementation (tvix) is addressing this as one of its core design goals, allowing evaluation and builds to run in parallel. But even once it's complete and usable, it's unclear what the relationship will be between tvix and Eelco's Nix.
Re: Deploying Containers on NixOS: A Guide
#55Earlier quoted context omitted.
I think it's also an issue with the flexibility paradox. There isn't a good single way to package Python for Nix because before you even start there are several key questions which come up that most other distros can't even begin reasoning about: - Are we packaging just one Python package for Nix, or a thing and all its dependencies? - Is the package already on PyPI, and are we packaging the source from there, or is…
I can't think of a single external packaging system that actually does Python non-painfully. Then again I can't think of an internal Python packaging system (there are like 5 now) that does Python non-painfully. But since one of the selling points of Nix is "it's like virtualenv but for everything", it's a little disappointing that it doesn't mesh better. I'm not a Python developer, though I use applications that req…
I think the Debian model is okay, it just falls down in terms of being able to have any kind of meaningful cooperation between the debs and what pip does, and of course there's the massive velocity mismatch between what's on PyPI and what's in your distro.... and of course no way to install more than one instance of something so heaven help you if you have two down-tree packages that depend on a different version of a thing.
Okay yeah no, even Debian pretty much sucks.
Re: Deploying Containers on NixOS: A Guide
#56Earlier quoted context omitted.
At the same time Nix implements python packaging particularly bad[1] when it does not have to. And that's on top of already insane state of python packaging. And poetry2nix becoming deprecated really bit me recently :/ Similar issues (minus insane packaging) is with Common Lisp packages, where there's annoying focus on compiling libraries into binaries (it would have been fine to have a bit of patching to provide thi…
I will say, there is one element of Nix's core design that makes almost all of these integrations considerably worse than they have to be, and that's the whole IFD fiasco— if it were possible to ingest an ecosystem-specific lockfile, run a build on it, and evaluate that result, then a lot of the drama and workarounds would melt away. This is sort of supported today, but it's basically banned from nixpkgs because of h…
That's honestly not the worst thing involved.
Another is that Nix as language is yet another of those "functional programming sounds fun, let's do bare minimal pure language and forget about all the niceties that proper ones figured out".
Re: Deploying Containers on NixOS: A Guide
#57Earlier quoted context omitted.
I will say, there is one element of Nix's core design that makes almost all of these integrations considerably worse than they have to be, and that's the whole IFD fiasco— if it were possible to ingest an ecosystem-specific lockfile, run a build on it, and evaluate that result, then a lot of the drama and workarounds would melt away. This is sort of supported today, but it's basically banned from nixpkgs because of h…
That's honestly not the worst thing involved. Another is that Nix as language is yet another of those "functional programming sounds fun, let's do bare minimal pure language and forget about all the niceties that proper ones figured out".
I think my argument is that most of those issues are relatively shallow— they're problems that could be addressed with tweaks to the syntax or additions to the standard library.
The IFD issue is fundamental. It's why poetry2nix has to be implemented entirely in Nix code in order to run at evaluation time without blocking, whereas in a world where eval and build could properly interleave, this would never be done— the core logic of poetry2nix would be implemented in something sane.
Re: Deploying Containers on NixOS: A Guide
#58Earlier quoted context omitted.
I can't think of a single external packaging system that actually does Python non-painfully. Then again I can't think of an internal Python packaging system (there are like 5 now) that does Python non-painfully. But since one of the selling points of Nix is "it's like virtualenv but for everything", it's a little disappointing that it doesn't mesh better. I'm not a Python developer, though I use applications that req…
I think the Debian model is okay , it just falls down in terms of being able to have any kind of meaningful cooperation between the debs and what pip does, and of course there's the massive velocity mismatch between what's on PyPI and what's in your distro.... and of course no way to install more than one instance of something so heaven help you if you have two down-tree packages that depend on a different version of…
And this isn't new: it was true for gems with Ruby, it was true for pear with PHP, it was true for CPAN with perl. I don't do javascript at all but I assume it's doubly true for npm just because that place seems to make even pypi look conservative and glacial. I've mostly come around to the belief that if an piece of software has a package manager you should just use it instead of your system package manager. But man do I miss the days of CPAN packages that might update once a year.
Re: Deploying Containers on NixOS: A Guide
#59Earlier quoted context omitted.
I think the Debian model is okay , it just falls down in terms of being able to have any kind of meaningful cooperation between the debs and what pip does, and of course there's the massive velocity mismatch between what's on PyPI and what's in your distro.... and of course no way to install more than one instance of something so heaven help you if you have two down-tree packages that depend on a different version of…
And this isn't new: it was true for gems with Ruby, it was true for pear with PHP, it was true for CPAN with perl. I don't do javascript at all but I assume it's doubly true for npm just because that place seems to make even pypi look conservative and glacial. I've mostly come around to the belief that if an piece of software has a package manager you should just use it instead of your system package manager. But man…
Generally I'm in agreement, but the one place that starts to fall apart is with bindings— if there's a native code library, then I really would prefer that library come in from the native package manager rather than be smuggled in by pip... but that's not generally how it works these days, and outside of Nix there isn't a great way to resolve this case.
Re: Deploying Containers on NixOS: A Guide
#60Earlier quoted context omitted.
These are a little chicken and egg as you need the system's host key for that. If you want to use a signed host key, you need to deploy that, otherwise if you just let it generate a host key you're in TOFU territory
I don't really feel like bootstrapping is that much work, since you usually need that public key to deploy the whole clojure anyway. Also, SCPing the file over is bad for reproducibility.
It’s finally happened, people are typo’ing closure as clojure, instead of the other way around!
For the topic at hand isn’t this always a problem with deployment systems? You need to have the secret somewhere after all. In my case I only ever use nix for personal systems, so feel totally justified just storing my ssh key as a secret in yadm.