>> "bad documentation" One thing I still can't figure out is if nix (or flakes) allows you to pin packages to a specific version. Does anyone now if that's possible and how? E.g. (pseudo code below) services.nginx.version="1.21.4" services.nginx.enable=true
You'd really need to set the package to a specific overridden version of nginx. See here for how to make such an override: https://blog.thomasheartman.com/posts/nix-override-packages-... . Then you would set `services.nginx.package = pkgs.nginx.override ...;`.
How Nix and NixOS get so close to perfect
81–90 of 183 posts
Re: How Nix and NixOS get so close to perfect
#82I’ve been trying out GUIX, but I wasn’t able to figure out a good way to do rust development on it. Tools like Cargo and Rust analyzer are extremely useful but introduce a lot of complexity which doesn’t seem to mix well with functional package managers like guix and nix.
Re: How Nix and NixOS get so close to perfect
#83I’ve been trying out GUIX, but I wasn’t able to figure out a good way to do rust development on it. Tools like Cargo and Rust analyzer are extremely useful but introduce a lot of complexity which doesn’t seem to mix well with functional package managers like guix and nix.
The main drawback of it is that it currently builds all of your dependencies in one big derivation, so any dependency changes cause a full rebuild. There's some other project I saw fly by which attempts to do a similar thing but split each crate into a separate derivation, but I forgot what it's called and have no experience with it.
[0]: https://github.com/nix-community/naersk
[1]: https://cs.tvl.fyi/depot/-/blob/ops/journaldriver/default.ni...
Re: How Nix and NixOS get so close to perfect
#84Earlier quoted context omitted.
You'd really need to set the package to a specific overridden version of nginx. See here for how to make such an override: https://blog.thomasheartman.com/posts/nix-override-packages-... . Then you would set `services.nginx.package = pkgs.nginx.override ...;`.
Thank you so much .
Re: How Nix and NixOS get so close to perfect
#85Earlier quoted context omitted.
Survivor of a cult does not necessarily mean that someone joined a cult themselves. Kids escaping environment they were born in may be survivors of a cult. People with spouses who joined a cult may be survivors. Environments may change, leaving a mainstream church in a specific area may mean leaving a cult. Etc. Don't look down on them unless you know all the details.
Sure, _one_ cult, but several? Mom being in the Shining Path and Dad in Heaven's Gate sounds like it would make for rather awkward dinners.
Re: How Nix and NixOS get so close to perfect
#86Earlier quoted context omitted.
> I don’t really think this is a problem at all? I mean, at the particular design point the language occupies there are basically three possibilities: How so? Where's the Java/Python-like languages in this consideration, why wouldn't those work? Or something more like Ansible? I'm pretty sure that you can express the same concepts for the most part in something imperative as well.
> Or something more like Ansible? If you make it more like Ansible, you will end up with ... Ansible. If you want to use Ansible you are perfectly welcome to, but as a Nix person the entire Ansible way looks like a completely wrongheaded approach to system management.
Ansible is “bottom-up” (you start in the middle of a server’s lifetime without knowing everything); many more cloudy solutions like Kubernetes assume that a bunch of infrastructure is already set up; container registries, build servers, and the control plane.
My first Ansible use-case was to install K3s on a dedicated machine where I could only choose the OS image from a few options like Debian and CentOS.
Re: How Nix and NixOS get so close to perfect
#87Earlier quoted context omitted.
I don't think JSON is a nice way to write config files at all. You can't even add comments. I'd much prefer something like Cue.
So long as the parser doesn't except on undefined keys, you can add pseudo-comments to many places in a JSON config file. { "foo": "bar", "COMMENT": "This bars the foo" }
Re: How Nix and NixOS get so close to perfect
#88I’ve been trying out GUIX, but I wasn’t able to figure out a good way to do rust development on it. Tools like Cargo and Rust analyzer are extremely useful but introduce a lot of complexity which doesn’t seem to mix well with functional package managers like guix and nix.
We use naersk[0] for Rust projects in our Nix monorepo (for example [1]). It's pretty hands-off in terms of the Nix code needed (you don't need to pin hashes inside of the Nix code as long as you have a Cargo lockfile) and all the existing tooling keeps working fine. The main drawback of it is that it currently builds all of your dependencies in one big derivation, so any dependency changes cause a full rebuild. Ther…
Re: How Nix and NixOS get so close to perfect
#89Earlier quoted context omitted.
Author of the post and survivor of several cults here. Nix is nothing like a cult. There is no behavior control, information control, thought control or emotion control at work. There are just people that are passionate about the tool and want to see it thrive. I would hardly call this a cult, more of just an interest group with weird nerds in it. Honestly after a while the language starts to fade into the background…
Quoted post unavailable.
Wow. I'm sure you have all the research and experience to vomit that psychoanalytic gem with authority.
Re: How Nix and NixOS get so close to perfect
#90As someone who really would like to have something like nix the thing that scares me away every time is the fact that the people creating this aparently did not think a lot about how to onboard users. And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...) don't really fill me with confidence that…
I've been working on things to help onboard people. If you wanted something to help onboard you with NixOS, what would you want to see?
"Use case -> how to achieve it", more than "functionality -> how to use it". Nixpills seems to flirt with both concepts, but also is a bit... showing off?
Just plain "I've got this app, how do I package it", "how do I overlay it", "why are there 5 ways of doing overlays that people use differently", "what is the actual expected signature of various flake elements", "what packaging helpers are available and how do I find them", ... would be amazing.
I have issues with nix docs trying to be clever. For example https://nixos.wiki/wiki/Overlays - "Careful, we're using a different self and super here!" - ok, then name them something more descriptive!