That creates containers, it doesn’t create multiple services. Those are not the same thing
That doesn’t make it any less inconsistent, though. And somebody may not necessarily be using nixpkgs, in which case they don’t have access to the lib methods at all. That’s the root of my complaint there; why are there builtins for and/or/xor but not for not? Clearly any one of them could have existed in nixpkgs code rather than natively, so why is not special?
Well, we’re both splitting hairs here, but it does meet your specified example of “run different versions of the same DB with a different ‘backing package’, on a different port” ;).
Generally speaking, you can pretty much always wire up nixos containers to effectively provide multiple versions of a given service, but it can take a fair bit of work, and it’s definitely less than I deal. I do think you are right, and that we would be much better off if there was a standard interface and set of implementation methods for doing multiple-instance service modules.
There’s several existing multiple-instance service modules in nixpkgs, and of course systemd provides templated service files, so there should be enough exemplars to analyse and draw inspiration from. Someone “just” needs to figure out a nice abstraction and implement it.
Of course, if you really want multiple services it is also possible to evaluate the services in separate NixOS instantiations, extract the service list entries and then add them into the service list of the main configuration.
Which is even less direct, of course…
(I know it works, because I extract service starter scripts out of NixOS services to use on non-NixOS)
The result depends on word size and handling of negative numbers, unlike and, or and xor. For instance, you’d want bitNot 0 to evaluate to 255 when working with individual octets of an IPv4 address. I think xoring with relevant constants (or use of (n: -1-n) in case of two’s complement arithmetic) is more appropriate to handle negation, even if it’s a bit more of a fuss.
Not only not: there are builtins.mul and builtins.div but no builtins.mod (while lib. has all three)
builtins. is not a core library like <stdio.h> or Prelude, it is just set of functions implemented in C++ rather than Nix.
Should it be a complete core library? Probably, yes. It is a topic to discuss.
But currently it is minimal set of functions which cannot be implemented on pure Nix (or the implementation in Nix would be very ineffective; in contrary builtins. has some high-level functions, which should not be in “core” library, but they are in in builtins. for performance reasons; so it has .concatMap but no .bitNot)
The derivation builtin is actually implemented in Nix code as a wrapper around derivationStrict. On my system the implementation is at /nix/store/6igqrrda7q52c4fc4wca7firf7rylpk6-nix-2.2.2/share/nix/corepkgs/derivation.nix (and the folder /nix/store/6igqrrda7q52c4fc4wca7firf7rylpk6-nix-2.2.2/share/nix/corepkgs/ is the sole entry of builtins.nixPath if NIX_PATH is empty). Surely we could provide other “builtins” using this same mechanism, so that way things like mod are available without nixpkgs?
Incidentally, the parent corepkgs dir has some other files in it, including a couple that define derivations (like one fetchurl.nix), but I don’t know what they’re for.
Is this public? I have a colleague interested in making use of bits of NixOS’ systemd stuff on non-NixOS systems, they might like to take a look. I would even if they don’t :P.
Is this public? I have a colleague interested in making use of bits of NixOS’ systemd stuff on non-NixOS systems, they might like to take a look. I would even if they don’t :P.
I wanted to generate systemd thingies with nix at some point and it’s a relatively extremely obscure corner of the system (you have to call some strange thing located in nixpkgs that processes the configuration set…? Something like that.) to extract them out of… +1 for doing a bit of a writeup on that or something. Please. That’s probably the serviceScript function.
I would encourage people to open separate issue for each papercut, no matter how small. This thread has quickly blown up and I doubt it is useful for anything other than venting frustrations now.
Unlike omnibus threads, small issues can be easily triaged, tagged and comments are not mixed up together like in linear discussion here.
You do not even need to be very specific in the issue description, we can always fill the details in later.
This isn’t meant to be a triaging/resolution thread, though. My main objective here is to basically inventory all the usability issues that people run into, including shaking out those that people would not bother filing an issue about, and those that aren’t solvable as individual issues but require more coordinated restructuring. They can then eventually be turned into actionable issues.
Even with an explicit “please file an issue” remark, filing an issue still tends to feel like a higher barrier than replying to a forum thread, to many people. Especially since for filed issues, users are normally expected to actually respond to follow-up questions, but in here they are not. This thread simply serves a different purpose from an issue tracker.
And I am actually reading each and every comment in this thread
Edit: also, “venting frustrations” is totally fine! That’s half the point of the thread, and it’s what shakes out the hidden usability issues.
It produces a comparator (function that takes two comparable objects and returns -1, 0, or 1, based on their relative ordering) from a predicate (function that takes an object and returns true or false, based on whether the thing belongs to a certain set) and two other comparators (one for objects in the set and other for the objects outside the set). Comparator can be passed to a sortBy function to obtain a collection (list) sorted according to the custom ordering represented by the comparator.
One thing this can be used for is to sort directories before files. Let’s have a list of attribute sets of the following structure { kind = "file"; fileName = "foo"; } and { kind = "dir"; dirName = "bar"; }. Sure, we could pass the following monstrosity to the sortBy function:
(a: b:
if a.kind == "dir"
then if b.kind == "dir" then compare a.dirName b.dirName else -1
else if b.kind == "dir" then 1 else compare a.fileName b.fileName)
but it is quite repetitive and easy to make mistake. The splitByAndCompare will be much cleaner
Once you gain a little familiarity with the idiom, it really is just a trivial combinator you will not spend more than a second thinking about.
In Haskell the nested conditional expressions in the definition can be further simplified by the fact that Ordering (of Bools produced by the partitioning function in this case) forms a semigroup:
splitByAndCompare :: (a -> Bool) -> (a -> a -> Ordering) -> (a -> a -> Ordering) -> (a -> a -> Ordering)
splitByAndCompare p yes no = \a b -> compare (p b) (p a) <> (if p a then yes else no) a b
My main problem with this thread is fact that Discourse is limited to linear discussions. The papercuts itself are lost here in the flood of possible solutions and meta-discussions like this one.
I also read every comment in this thread but every time I decide I want to tackle one of them, I need to sift through the whole thread and rule out non-actionables again. On the issue tracker, triagers can rename, tag and fill in the details to the issues once and for all. Here, I have to do it repeatedly and in my head.
I did not mean that venting is somehow bad but I would say doing it here has pretty high chance of having no effect other than a temporary mental relief for the poster. I and many other people go through the issue tracker repeatedly and triage issues there or periodically choose ones to fix. If one copies the short paragraph to the issue tracker, there is much higher chance of something being done about it.
I would say that our issue tracker has quite low barrier of entry. I have personally elaborated on or even fixed several issues that consisted of single vague sentence. People can always unsubscribe if the issue is less annoying to them than follow-ups. Maybe reducing the perceived threshold is another papercut we can work on.
If the purpose of this thread is to inventorize, who will do the turning into issues? I started working on this by copying the thread to a text editor but the sheer size of this thread made me give up immediately. So even if this thread has low barrier of entry to reporters, it has incredibly high barrier of entry to implementers.
I do not discount the interest point mentioned by @JohnAZoidberg but if you care even a little, consider opening an issue in addition to posting here.
I gave shortening my invevitably overlong post a go: I think the reason this is in the forum and not the issue tracker is because
open question
“venting” is “allowed”
no mental commitment
If you don’t have the energy or will time or similar to sift through the thread I think that’s OK. At least joepie seems to have volunteered for dealing with the aftermath here and we have so many things to do anyway that slow and steady progress seems to be the only way to go - but sorry I’m preaching to the choir.
It’s just another way to gather community feedback.
The issue tracker does seem like a good idea to “canonicalize” at though.
I think (based on an experience last night) that nix configuration settings in configuration.nix only take effect if the rebuild succeeds, not during the rebuild itself. So previous state applies to the building of new state.
Example: I tried to add a custom package to configuration.nix using fetchgitPrivate and ssh agent forwarding. This didn’t work because I had to set nix.enableSandbox = false. But setting this didn’t fix the problem because it didn’t take effect because it couldn’t build the package! So I had to remove the package from configuration.nix, leave enableSandbox=false in there, do a rebuild, and then put the package back in.
(Disclaimer: I’m new to all this so I could have completely misinterpreted what went wrong.)
You are correct. /etc/nix/nix.conf doesn’t have any special handling, and changes to it are only made during profile activation (following a successful build of the profle). If you absolutely need to make a change to it in order to build a new profile generation, you can do something like:
cd /etc/nix
mv nix.conf nix.conf.link # The file is a symlink to a store path, so you can't edit it directly
cp nix.conf.link nix.conf
chmod u+w nix.conf
vi nix.conf # Make required changes
systemctl stop nix-daemon.service # The daemon will restart itself on next use via socket-activation from nix-daemon.socket
nixos-rebuild switch