Nix is slowly becoming a major point of contention. In some communities, it’s already scary to even hint that one dislikes it.
[deleted]
Nix is the ultimate DevOps toolkit
151–160 of 243 posts
Re: Nix is the ultimate DevOps toolkit
#152Earlier quoted context omitted.
As somebody who wants to try out nix, but has almost no knowledge of it, I would like to find resources that show the "right" way, or perhaps the "best" way to use nix. Do you know of existing documentation that explains that, according to your opinion?
I think https://nix.dev is what you are looking for. It's a really great resource (and no need to go all in and do _everything_ in nix)
This is orders of magnitude more useful than the official docs.
Re: Nix is the ultimate DevOps toolkit
#153Has anyone explored CD tooling with Nix? And I don't mean the deployment of NixOS machines themselves (NixOps, deploy-rs, etc), I mean actually using Nix for deployment tooling and orchestrating deployments using the Nix language. I am yet to find any posts about this or any tools, but have had great success with a small hand rolled tool that essentially lets me decoratively describe cloud resources, parts of my appl…
In addition to the other comments, there is also nixops. [1]
Re: Nix is the ultimate DevOps toolkit
#154Earlier quoted context omitted.
I am of a similar opinion, but I think it's largely due to my typical use case. If you use Nix in a "drive-by" kind of way, it's very hard to make any inroads into the language. The documentation and tutorials are not really intended for a casual user - it is expected you will sit down with the Nix site like a good book, and go at it from start to finish. If (like me) you instead touch Nix little and often, doing sma…
> If you use Nix in a "drive-by" kind of way, it's very hard to make any inroads into the language. The documentation and tutorials are not really intended for a casual user - it is expected you will sit down with the Nix site like a good book, and go at it from start to finish. If (like me) you instead touch Nix little and often, doing small invocations or on-the-fly editing, the docs are much less useful. This is s…
There are some serious gotchas like nix-env in this read I would like to delete. But, that said, I don't think targeting "drive by usesr" is worth it.
The benefits of Nix is that it dramatically organizes the absolute disgusting mess that is how most people manage their computer. I don't want to drive people trying things out away, but Nix will never be worth it unless you embrace it, and half-ways usage will deliver all the downsides without enough of the upsides.
Not every value function is monotonic like that, I am not going to pretend it's otherwise.
The goal is to help people fully embrace it, not to allow them to comfortably come to a stand-still half way.
Re: Nix is the ultimate DevOps toolkit
#155Obligatory link to its cousin: https://guix.gnu.org/ A package manager or a full distro. I use the package manager on top of Debian, it's great, it allows me to get recent package versions the most straightforward way (like the latest Emacs), in exchange of disk space (easily some GB before a `guix gc` cleanup).
Guix is definitely a cleaner implementation (coherent cli tooling, way better manual, not a custom, oddball language, ...).
But:
* if Nix is already very niche, Guix is the niche of a niche. The ecosystem is tiny in comparison.
* The Nix interpreter isn't exactly fast, but Guix (with it's scheme) was significantly worse for me, even in relatively small tests
* The hard stance on open source requirements is understandable, given the projects origin, but it will severely hinder adoption. No, I don't want to package every commercial app I need myself. nixpkgs has almost everything.
Re: Nix is the ultimate DevOps toolkit
#156Earlier 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…
> By default, any change to any dependency will cause all dependent derivations to be rebuilt, and their hashes to also change. You can 'break' this by introducing stable ABI barriers preventing rebuilds and performing runtime loads of dependencies from .so (or whatever, executing some binaries from $PATH). Does this imply full control over hash holding/breaking for derivation authors, or is it like a single field th…
It's full control; remote files, for example will have an hash which you inline [1] so that the resultant hash is correctly computed.
[1] https://github.com/NixOS/nixpkgs/blob/842f900e73c7ce985218cc...
Re: Nix is the ultimate DevOps toolkit
#157The gotcha I have with Nix is it's too much abstraction. I have to look at the upstream documentation, then try and map it to Nix's config syntax, then hope everything works. Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, an…
What the hell is the second part? Are people really installing software as part of the normal workflow of some deployment? Unless the thing is supposed to be some sort of heroku like thing, that's insane.
Re: Nix is the ultimate DevOps toolkit
#158Earlier quoted context omitted.
That is a gross oversimplification. An javascript front end can have thousands of dependencies, and the nix build environment does not have network access unless it's computing a fixed output. To do that manually would be a nightmare, so you must automated either with tools you write or tools someone else has written. Then you still have to figure out how to combine it all together. Also on allowing network access in…
> That is a gross oversimplification It's really not. I've used this successfully for Javascript projects (running npm and yarn), Python projects (running pip install), Scala projects (running sbt), Haskell projects (running cabal), Racket projects (running raco), Go projects (running go get), etc. It's pretty much like writing a Makefile, except we have to specify the buildInputs, and there are occasional annoyances…
>> which means you cannot do that method on environments you don't have full control.
> Could you give an example of where that would ever be an issue? The only thing I can think of is hydra.nixos.org, but there's no way in hell such a derivation would be acceptable for nixpkgs, so that's pretty irrelevant (similar to how it's really easy to make a .deb package from a directory and a control file; but there's no way in hell it complies with the Debian project's packaging guidelines)
In any production environment, using any external build service like nixbuild.net, self-host hydra. Basically anything beyond personal use.
The post about all this is from Channable, Channable runs nix built code in production. Their developers (likely) cannot disable the sandbox and ship that code.
You even say that there is "no way in hell such a derivation would be acceptable for nixpkgs"
If you cannot share it, it's only good for you and you alone.
Re: Nix is the ultimate DevOps toolkit
#159Chef's Habitat is a really powerful nix-like system that I find to be a bit more practical. Like nix though it suffers from being a complete paradigm shift that people coming in from the imperative OS world struggle trying to map their existing patterns into
It's kind of sad because it's a far better way to manage deployments and environments...but it takes 1-2 years of practice to really get proficient at
Re: Nix is the ultimate DevOps toolkit
#160Earlier quoted context omitted.
Try telling it to any recruiter lol
The problem "containers" solve does not exist in nix land. If all you've got is a hammer... Edit: removed "clouds"
Nix does not solve all problems clouds solve. But it can be a quite useful tool combined with them.