4 ms·

I've been trying to get a nix file running today, and the terminology definitely gets arcane very fast. I also have the feeling that the tutorials start with t

by carlmr 6y ago

I've been trying to get a nix file running today, and the terminology definitely gets arcane very fast. I also have the feeling that the tutorials start with the details, instead of starting with an overview so you can understand what is what. This is guide us already very helpful and I think one should read it before the official tutorial. Thank you!

tomberek 6y ago
Got a project or want some guidance? I can help out.
- thibran 6y ago
  Question 1 - What is the correct way to build and install self created derivations? Right now I have a custom fish function: function nix-local-build nix-build --no-out-link \ -E '(import <nixpkgs> {}).callPackage ./'$argv[1]' {}' end To build and install something I run: nix-local-build some.nix nix-env -i [store-path-from-build] The .nix file is in the same format as e.g. pkgs/tools/misc/bat/default.nix. Question 2 - How to include such a derivation into configuration.nix?
  - nomurrcy 6y ago
    Overlays can be very helpful for this type of thing. I have overlays in ~/.config/nixpkgs/overlays.nix (though you do this various ways) My overlay file has the form: let my-packages-overlay = self: super: { foo = super.callPackage ./path/to/package.nix {} } in [ my-packages-overlay ] Then you can just nix-env -iA your-package. See: https://nixos.wiki/wiki/Overlays https://nixos.wiki/wiki/Overlays
    - mason55 6y ago
      > Then you can just nix-env -iA your-package. This is what always gets me stuck. It seems like lots of tutorials assume you're installing packages by hand still. For me, the whole reason I'm using nix is so that I can use the declarative package management. I get having local dev dependencies on a per-project basis and running a nix shell to make those dependencies available in your development environment. But it's just confusing to me how many tutorials suggest running nix-env -i to imperatively install a package. Why would I do that instead of taking advantage of the joys of declarative package management?
      - nvarsj 6y ago
        I've never used nix-env on NixOS. I really think that command only exists as a bridge for people used to more traditional OS's. I think there is a space for it - if you don't want to spend time building your user configuration declaratively, just install what you need and get going.
      - takeda 6y ago
        Because Nix is a language there are many ways of accomplishing the same thing. Some ways are easier, some require more work. For example if you make a derivation in your home, it is easy to install it with nix-env from there, and you are done, but if you want to include it in your configuration, you typically would create an overlay that includes your package in nixpkgs. Then you can list the package. If your derivation requires creating a configuration, service etc. On top of that you will also need to create module that specifies configuration options and configures the application. So in many cases you are told to use nix-env, because the person just answered how to write a derivation and didn't go further than that. I think flakes (still work in progress), will help here, because it defines a standard that supposed to do all of that in one file that is easily composable.
  - tomberek 6y ago
    Question 1: That is a reasonable way to build and install. I normally structure things like this (https://www.reddit.com/r/NixOS/comments/8tkllx/standard_project_structure/ https://www.reddit.com/r/NixOS/comments/8tkllx/standard_proj...) where the Nixpkgs-compatible derivation is in derivation.nix and the default.nix or overlay.nix contains the "callPackage" portion. Question 2: including such a derivation is easy with overlays or with the method above. drv = import ./path-to-derivation.nix; package = pkgs.callPackage drv {}; or something similar can work. Overlays would be slightly more re-usable, but would take a few more expressions. I'd do that if there are multiple packages you need to introduce; I normally use overlays to manage groups of interdependent packages, a "meta-package".
    - thibran 6y ago
      Thanks a lot for this :)
  - takeda 6y ago
    Just to add to what others said regarding question 2. After you write a derivation that you can build, you need to create a module [1]. The module defines configuration options, then takes the donation and does other things such as creating service users (if needed), services and configurations. Then you simply import it and use it. Regarding question 1 what was suggested by others is what is the current way of doing it, but I will recommend to go through Nix Pills[2]. The author starts with making a simple derivation and then starts introducing conventions. The conventions make things more complex, but they make things more flexible. I can't wait for Flakes[3], they will standardize a lot of this, removing extra cruft and allowing things to be more composable. [1] https://nixos.org/nixos/manual/index.html#sec-writing-modules https://nixos.org/nixos/manual/index.html#sec-writing-module... [2] https://nixos.org/nixos/nix-pills/index.html https://nixos.org/nixos/nix-pills/index.html [3] https://www.tweag.io/blog/2020-05-25-flakes/ https://www.tweag.io/blog/2020-05-25-flakes/
    - thibran 6y ago
      Thanks for the links. Flakes seem to be a good way forward. I've even read most Nix Pills posts, but didn't like them much. Too many details about things that I didn't understand at the time of reading, so the why got lost. In Nix you get a lot of details, what is missing is often the why and how. For example I wanted to have a CLI command available with a binary build, finding out how to add the CLI tool to the package through wrapProgram in postInstall wasn't fun. Overall Nix is awesome, but here and there it is hell of a lot frustrating. After reading so many hours I should not have to ask how to install a custom package the right way.
tarkin2 6y ago
> I also have the feeling that the tutorials start with the details, instead of starting with an overview Yes. Reading the official docs, or Nix pills, gives exactly this impression. I've read some good documentation away from the official docs on how to start using the package manager. But understanding the overview of how to package things yourself is all wood and no trees. There's so many moving parts in nix that knowing how they all interact, and which ones are important for your task at hand, is a headache.
clhodapp 6y ago
I also have the feeling that the tutorials start with the details, instead of starting with an overview so you can understand what is what. When you are trying to be as different from everything else as wide-reachingly as Nix is, it seems to work better to build an understanding up rather than down. This seems to frustrate a lot of people because it does not give much payoff for the first few hours of learning (and that's a lot to invest to even understand what something is). The truth is that Nix is really really complicated (expect a year-long learning curve to truly "get" everything), but it's also really hard to take the more-standard approaches to building packages and managing machines seriously once all the pieces finally do all connect. Unfortunately, it kind of makes one feel like being an early adopter of git in a world where no one else uses version control. It's like, "Yes, this is way better, but I'm not going to be able to get anyone else to use it."
- nvarsj 6y ago
  This is well described. Nix is fundamentally a different way to manage an OS compared to almost anything out there. While I think the ideas behind it are revolutionary and is the right way to build infra, the UX and organic growth of it makes it fairly difficult to get into - so there is unfortunately a steep learning curve. I think I sunk a solid 40 hours into building a declarative config for my own dev machine before I had a decent (but far from complete) understanding. But once you grasp it, it is quite mind blowing, and you wonder how anyone could cope with traditional mutable systems and the associated temperamental config management. I think Guix might be the answer as a more approachable implementation of the Nix ideas, using Scheme for its config language. I haven't spent much time with it but I got going a lot quicker initially compared to Nix.
  - takeda 6y ago
    > I think Guix might be the answer as a more approachable implementation of the Nix ideas, using Scheme for its config language. I haven't spent much time with it but I got going a lot quicker initially compared to Nix. Out of curiosity, did you tried Guix before trying Nix or vice versa? When looking at Guix myself, all I see is that the derivations are just wrapped in parentheses otherwise they do look similar. So I'm wondering if scheme actually brings anything here, especially for someone not familiar with a functional language. IMO Nix language isn't actually that hard, I believe the most complexity comes from nixpkgs and still not adequate documentation of it, so one needs to study its source code.

by carlmr 6y ago

tomberek 6y ago

Got a project or want some guidance? I can help out.

thibran 6y ago
Question 1 - What is the correct way to build and install self created derivations? Right now I have a custom fish function: function nix-local-build nix-build --no-out-link \ -E '(import <nixpkgs> {}).callPackage ./'$argv[1]' {}' end To build and install something I run: nix-local-build some.nix nix-env -i [store-path-from-build] The .nix file is in the same format as e.g. pkgs/tools/misc/bat/default.nix. Question 2 - How to include such a derivation into configuration.nix?
- nomurrcy 6y ago
  Overlays can be very helpful for this type of thing. I have overlays in ~/.config/nixpkgs/overlays.nix (though you do this various ways) My overlay file has the form: let my-packages-overlay = self: super: { foo = super.callPackage ./path/to/package.nix {} } in [ my-packages-overlay ] Then you can just nix-env -iA your-package. See: https://nixos.wiki/wiki/Overlays https://nixos.wiki/wiki/Overlays
  - mason55 6y ago
    > Then you can just nix-env -iA your-package. This is what always gets me stuck. It seems like lots of tutorials assume you're installing packages by hand still. For me, the whole reason I'm using nix is so that I can use the declarative package management. I get having local dev dependencies on a per-project basis and running a nix shell to make those dependencies available in your development environment. But it's just confusing to me how many tutorials suggest running nix-env -i to imperatively install a package. Why would I do that instead of taking advantage of the joys of declarative package management?
    - nvarsj 6y ago
      I've never used nix-env on NixOS. I really think that command only exists as a bridge for people used to more traditional OS's. I think there is a space for it - if you don't want to spend time building your user configuration declaratively, just install what you need and get going.
    - takeda 6y ago
      Because Nix is a language there are many ways of accomplishing the same thing. Some ways are easier, some require more work. For example if you make a derivation in your home, it is easy to install it with nix-env from there, and you are done, but if you want to include it in your configuration, you typically would create an overlay that includes your package in nixpkgs. Then you can list the package. If your derivation requires creating a configuration, service etc. On top of that you will also need to create module that specifies configuration options and configures the application. So in many cases you are told to use nix-env, because the person just answered how to write a derivation and didn't go further than that. I think flakes (still work in progress), will help here, because it defines a standard that supposed to do all of that in one file that is easily composable.
- tomberek 6y ago
  Question 1: That is a reasonable way to build and install. I normally structure things like this (https://www.reddit.com/r/NixOS/comments/8tkllx/standard_project_structure/ https://www.reddit.com/r/NixOS/comments/8tkllx/standard_proj...) where the Nixpkgs-compatible derivation is in derivation.nix and the default.nix or overlay.nix contains the "callPackage" portion. Question 2: including such a derivation is easy with overlays or with the method above. drv = import ./path-to-derivation.nix; package = pkgs.callPackage drv {}; or something similar can work. Overlays would be slightly more re-usable, but would take a few more expressions. I'd do that if there are multiple packages you need to introduce; I normally use overlays to manage groups of interdependent packages, a "meta-package".
  - thibran 6y ago
    Thanks a lot for this :)
- takeda 6y ago
  Just to add to what others said regarding question 2. After you write a derivation that you can build, you need to create a module [1]. The module defines configuration options, then takes the donation and does other things such as creating service users (if needed), services and configurations. Then you simply import it and use it. Regarding question 1 what was suggested by others is what is the current way of doing it, but I will recommend to go through Nix Pills[2]. The author starts with making a simple derivation and then starts introducing conventions. The conventions make things more complex, but they make things more flexible. I can't wait for Flakes[3], they will standardize a lot of this, removing extra cruft and allowing things to be more composable. [1] https://nixos.org/nixos/manual/index.html#sec-writing-modules https://nixos.org/nixos/manual/index.html#sec-writing-module... [2] https://nixos.org/nixos/nix-pills/index.html https://nixos.org/nixos/nix-pills/index.html [3] https://www.tweag.io/blog/2020-05-25-flakes/ https://www.tweag.io/blog/2020-05-25-flakes/
  - thibran 6y ago
    Thanks for the links. Flakes seem to be a good way forward. I've even read most Nix Pills posts, but didn't like them much. Too many details about things that I didn't understand at the time of reading, so the why got lost. In Nix you get a lot of details, what is missing is often the why and how. For example I wanted to have a CLI command available with a binary build, finding out how to add the CLI tool to the package through wrapProgram in postInstall wasn't fun. Overall Nix is awesome, but here and there it is hell of a lot frustrating. After reading so many hours I should not have to ask how to install a custom package the right way.

tarkin2 6y ago

> I also have the feeling that the tutorials start with the details, instead of starting with an overview Yes. Reading the official docs, or Nix pills, gives exactly this impression. I've read some good documentation away from the official docs on how to start using the package manager. But understanding the overview of how to package things yourself is all wood and no trees. There's so many moving parts in nix that knowing how they all interact, and which ones are important for your task at hand, is a headache.

clhodapp 6y ago

I also have the feeling that the tutorials start with the details, instead of starting with an overview so you can understand what is what. When you are trying to be as different from everything else as wide-reachingly as Nix is, it seems to work better to build an understanding up rather than down. This seems to frustrate a lot of people because it does not give much payoff for the first few hours of learning (and that's a lot to invest to even understand what something is). The truth is that Nix is really really complicated (expect a year-long learning curve to truly "get" everything), but it's also really hard to take the more-standard approaches to building packages and managing machines seriously once all the pieces finally do all connect. Unfortunately, it kind of makes one feel like being an early adopter of git in a world where no one else uses version control. It's like, "Yes, this is way better, but I'm not going to be able to get anyone else to use it."

nvarsj 6y ago
This is well described. Nix is fundamentally a different way to manage an OS compared to almost anything out there. While I think the ideas behind it are revolutionary and is the right way to build infra, the UX and organic growth of it makes it fairly difficult to get into - so there is unfortunately a steep learning curve. I think I sunk a solid 40 hours into building a declarative config for my own dev machine before I had a decent (but far from complete) understanding. But once you grasp it, it is quite mind blowing, and you wonder how anyone could cope with traditional mutable systems and the associated temperamental config management. I think Guix might be the answer as a more approachable implementation of the Nix ideas, using Scheme for its config language. I haven't spent much time with it but I got going a lot quicker initially compared to Nix.
- takeda 6y ago
  > I think Guix might be the answer as a more approachable implementation of the Nix ideas, using Scheme for its config language. I haven't spent much time with it but I got going a lot quicker initially compared to Nix. Out of curiosity, did you tried Guix before trying Nix or vice versa? When looking at Guix myself, all I see is that the derivations are just wrapped in parentheses otherwise they do look similar. So I'm wondering if scheme actually brings anything here, especially for someone not familiar with a functional language. IMO Nix language isn't actually that hard, I believe the most complexity comes from nixpkgs and still not adequate documentation of it, so one needs to study its source code.