61–70 of 243 posts
I love nix as a concept, but in my experience it isn't practical on systems without a ton of memory. I regularly get build errors due to oom errors.
A lot of this sounds familiar to me— I maintain a hodgepodge build tool/pipeline at my org whose current output is a monolithic mega-deb file which is becoming unwieldy on several fronts (storage, transfer, compression time). I'm really interested in the nix philosophy of separate paths and versioning by hash rather than number, but unfortunately my needs are quite specific, and not having actual experienced nix expe…
> What is the story in nix for packaging untagged branches of software, or reasoning about "snapshots" where pools of unreleased repos/packages are able to be treated as a single versionable unit? A Nix derivation (a.k.a. 'packaging unit') can be built from sources either fetched remotely, or from a local directory, or a combination of both; plus any other derivation that it depends on. Any version semantics come fro…
This is not true and no hacks are needed. Since nix only depends on /nix it can be used in combination with ANY linux OS.
In fact there is an official debian binary for nix: https://packages.debian.org/bullseye/nix-bin
Earlier quoted context omitted.
> What is the story in nix for packaging untagged branches of software, or reasoning about "snapshots" where pools of unreleased repos/packages are able to be treated as a single versionable unit? A Nix derivation (a.k.a. 'packaging unit') can be built from sources either fetched remotely, or from a local directory, or a combination of both; plus any other derivation that it depends on. Any version semantics come fro…
> Not aware of anything out of the box. Nix builds only run on Nix (as they all need dependencies from /nix/store/..., and that is populated by Nix itself), so don't expect to easily run them on Debian without some disgusting home-rolled hacks. You could technically consume binary .debs from Debian within nix derivations (see previous point), but that's ugly. This is not true and no hacks are needed. Since nix only d…
I tried Nix a few days ago. I set it up on an existing Arch install. I installed a couple of packages with "nix-env -i [package] and then tried to update them with "nix-env -u" as instructed in the official documentation: https://nixos.org/manual/nix/stable/#ch-basic-package-mgmt This ended up breaking the entire install. After a few hours of troubleshooting I found that the reason it broke was that it updated itself…
The correct way is to search for packages as the following: https://nix.dev/tutorials/ad-hoc-developer-environments.html...
And then install via: nix-env -iA attribute-name
New Nix CLI as part of next release fixes that, but it's not out yet.
I tried Nix a few days ago. I set it up on an existing Arch install. I installed a couple of packages with "nix-env -i [package] and then tried to update them with "nix-env -u" as instructed in the official documentation: https://nixos.org/manual/nix/stable/#ch-basic-package-mgmt This ended up breaking the entire install. After a few hours of troubleshooting I found that the reason it broke was that it updated itself…
I wish Nix would just get rid of nix-env. It's not the way it's meant to be used, you should be using "nix run" or nix-shell for temporary usage, and home-manager for dotfiles and user dependencies. Using Nix like an imperative package manager is not really an improvement over existing ones, the declarative bit is where it truly shines.
The language and documentation is pretty awful, however I use NixOS (and therefore Nix) on my work desktop and still absolutely love it. The ability to create reproducible builds, test out tools without installing them permanently, and roll the OS back if you break something is just excellent. For example I spent ages this morning trying to get a gRPC Rust environment working and battled the nix file for a good two h…
Do you truly understand how it works though? I was similar. I loved my setup and it did mostly just "work" but I found it unnerving that eventually when it does break, I wouldn't know how to fix it.
A lot of this sounds familiar to me— I maintain a hodgepodge build tool/pipeline at my org whose current output is a monolithic mega-deb file which is becoming unwieldy on several fronts (storage, transfer, compression time). I'm really interested in the nix philosophy of separate paths and versioning by hash rather than number, but unfortunately my needs are quite specific, and not having actual experienced nix expe…
Most Nix packages define their sources using `src`. You can pass in whatever you want. E.g. fetch a tarball from GitHub with `fetchUrl`, fetch from a git repository, or point to a local directory.
> or reasoning about "snapshots" where pools of unreleased repos/packages are able to be treated as a single versionable unit?
This is basically what the Nixpkgs collection is minus the "unreleased" part. You can extend Nixpkgs with the packages that you care about using overlays. You have control over the stuff that you put in the overlay, so you can put in unreleased software as well like I described above.
> - I have an existing system for managing packaging metadata which I don't want to migrate from. How much trouble will I get into if I want to generate the metadata on the fly each time (as I currently do for my debs)?
This is difficult to answer without knowing more details.
- You can generate the Nix source files based on the metadata like the sibling comment pointed out.
- Or you could read the metadata with `builtins.fromJSON` and generate Nix derivations programmatically from within Nix.
> - What is the apt/nix interop story?
If you don't want to bother packaging certain applications using Nix (or work towards that gradually), you can. Nothing prevents you from referencing things outside of `/nix/store` in a Nix package. You can launch stuff from `/usr/bin` from a Nix binary if you are so inclined. Libraries are going to be tricky though.
As for the other way around, I'm aware of two options:
- At Channable, we would package the Nix closure of a package in a `.deb`. This works, but you run into trouble when multiple debs need the same store path. You can work around this by packaging the Nix closure under e.g. `/var/lib//nix/store` and bind mounting to `/nix/store` before launching.
- Eventually we realized we didn't want the `/nix/store` stuff in our `.deb` packages. IIRC we created a `postinst` script which ran `nix-env` to realize a store path from our cache + create a GC root so it doesn't get garbage collected.
Some of that stuff may have changed since I left.
Feel free to contact me if you'd like to discuss further. Info is in my profile.
Earlier quoted context omitted.
Actually, I found the language to be pretty similar to Haskell, if you do know that. You don’t have explicit functions, you use let in, and everything is an exception. It is even lazy evaluating.
The lack of lazy evaluating is an issue as the Nixpkg grows. I don't believe anyone has a solution to this yet.
Also, check out flakes, which somewhat steers away from the central repo design.
Nice, but this is as far from devops as knitting. They covered CI, but there is CD, all the cloud stuff, containers, security and so on.