4 ms·

My current objective is to make an easy and reproducible configuration + live image installer. I want to automate the whole process. As soon as I plug in the US

My current objective is to make an easy and reproducible configuration + live image installer. I want to automate the whole process. As soon as I plug in the USB stick, my preferred defaults should do their work without user input. Although, I really don't like Nix as a language. I really wish it would have used something like GNU Guile. Searching deep for nuggets of information isn't nearly as painful as the language itself. I might adapt to it in time, but still.

mr337 4y ago
Not for sure if you are working on SD card based things but this might get you half way there. We do this for loading RPIs https://github.com/Robertof/nixos-docker-sd-image-builder https://github.com/Robertof/nixos-docker-sd-image-builder
tomberek 4y ago
Can you clarify what parts you don't like. I think it's important to distinguish so I know what portions to work on (and figure out how to fix it). Is it: the language syntax itself, the idioms used in Nixpkgs, the module system, the common frameworks used to create package sets, or something else?
- eximius 4y ago
  The language is in a weird place. The language itself is okay, but you're often trying to use the language to compute a result that meets an interface that is never defined. There is very poor ability to reason about the 'types'/shapes of arguments or the semantics of what outputs should conform to. It seems to require either 1) deep knowledge about the orchestration of the evaluation of the key files you interact with (e.g., what the inputs to configuration.nix will be) or 2) reading many, many examples which eventually have the hints you want.
  - eximius 4y ago
    Flakes may be a step in the right direction, but I admit I've somewhat halted my journey after finally grokking how to use nix channels and configuration.nix. I haven't done any packaging or gotten into flakes as a unit of composable configuration. I know flakes are intended to make these things easier, but even the 'specification' for what makes a valid flake seems awfully vague.
    - baby 4y ago
      It’s super vague. The only way I could find to understand how to create a flake (for https://mimoo.github.io/nixbyexample/ https://mimoo.github.io/nixbyexample/) was trial and error and diving into the nix codebase.
  - infogulch 4y ago
    > There is very poor ability to reason about the 'types'/shapes of arguments or the semantics A new configuration language designed to work with Nix, Nickel https://nickel-lang.org/ https://nickel-lang.org/ looks like a step in the right direction, but I think the language design of CUE https://cuelang.org/ https://cuelang.org/ is the largest local maxima in the expressiveness / complexity tradeoff that we've found. Nickel is inspired by CUE, but I'm concerned that they're stumbling over the design (#1121) due to missing one of the headlining features of CUE, the U: Unification.
  - baby 4y ago
    This ^ When I write Rust I understand exactly what structs I’m creating due to the typesystem + the excellent documentation. In Nix I’m always lost. What struct should my flake function return? What arguments can it take? Etc.
    - tomberek 4y ago
      As we make flakes stable, this will improve as the docs can prioritize this information, and tooling can focus on making this more clear. On a much longer horizon, future Nix language (eg: Nickel) improvements provide a gradual typing system. On a short-term, I'm trying to provide some opinionation and a framework to describe this (https://floxdev.com/docs/custom-packages/ https://floxdev.com/docs/custom-packages/) . The challenge is to provide enough simplicity, but not so much that one loses the very benefits we are trying to achieve.
      - eximius 4y ago
        Why does it need to be gradually typed? If there was the equivalent to Rust doc generation that said `fn configuration(config: Config, pkgs: Packages) -> Configuration` "Implement this function in `/etc/nixos/configuration.nix" And then I could click into each type and see what it's supposed to be, etc. Now, there would be some differences because Rust can't have arbitrary record types but you can imagine either forcing packages to define their inputs or just take the idea of rust doc here as a visual example. But being able to progressively drill down the types - and have the types checked by the language runtime! - would massively improve Nix's ease of use and discoverability.
        pxc 4y ago
        > Why does it need to be gradually typed? Because one of the things that's nice about using Nix as a consumer of Nix libraries is that for simple use cases, your code can be so simple that it truly resembles a plain configuration file. By implementing a gradual type system, Nickel allows producers of Nickel libraries to enrich their code with helpful type annotations without making all of the code consuming those libraries verbose or cumbersome. > being able to progressively drill down the types - and have the types checked by the language runtime! - would massively improve Nix's ease of use and discoverability. That definitely seems to be the goal. If you wanna get a feel for how Nickel looks today, you should try translating the exercises from the old Tour of Nix¹ on the new Nickel Playground²! The lead dev is very friendly and receives feedback warmly. 1: https://nixcloud.io/tour/?id=1 https://nixcloud.io/tour/?id=1 2: https://nickel-lang.org/playground https://nickel-lang.org/playground
schemescape 4y ago
Did you mention Guile because of Guix? If not, you might be interested in GNU Guix.
Ericson2314 4y ago
https://github.com/NixOS/rfcs/pull/136 https://github.com/NixOS/rfcs/pull/136 soon, you shouldn't have to care what language it uses!

mr337 4y ago

Not for sure if you are working on SD card based things but this might get you half way there. We do this for loading RPIs https://github.com/Robertof/nixos-docker-sd-image-builder https://github.com/Robertof/nixos-docker-sd-image-builder

tomberek 4y ago

Can you clarify what parts you don't like. I think it's important to distinguish so I know what portions to work on (and figure out how to fix it). Is it: the language syntax itself, the idioms used in Nixpkgs, the module system, the common frameworks used to create package sets, or something else?

eximius 4y ago
The language is in a weird place. The language itself is okay, but you're often trying to use the language to compute a result that meets an interface that is never defined. There is very poor ability to reason about the 'types'/shapes of arguments or the semantics of what outputs should conform to. It seems to require either 1) deep knowledge about the orchestration of the evaluation of the key files you interact with (e.g., what the inputs to configuration.nix will be) or 2) reading many, many examples which eventually have the hints you want.
- eximius 4y ago
  Flakes may be a step in the right direction, but I admit I've somewhat halted my journey after finally grokking how to use nix channels and configuration.nix. I haven't done any packaging or gotten into flakes as a unit of composable configuration. I know flakes are intended to make these things easier, but even the 'specification' for what makes a valid flake seems awfully vague.
  - baby 4y ago
    It’s super vague. The only way I could find to understand how to create a flake (for https://mimoo.github.io/nixbyexample/ https://mimoo.github.io/nixbyexample/) was trial and error and diving into the nix codebase.
- infogulch 4y ago
  > There is very poor ability to reason about the 'types'/shapes of arguments or the semantics A new configuration language designed to work with Nix, Nickel https://nickel-lang.org/ https://nickel-lang.org/ looks like a step in the right direction, but I think the language design of CUE https://cuelang.org/ https://cuelang.org/ is the largest local maxima in the expressiveness / complexity tradeoff that we've found. Nickel is inspired by CUE, but I'm concerned that they're stumbling over the design (#1121) due to missing one of the headlining features of CUE, the U: Unification.
- baby 4y ago
  This ^ When I write Rust I understand exactly what structs I’m creating due to the typesystem + the excellent documentation. In Nix I’m always lost. What struct should my flake function return? What arguments can it take? Etc.
  - tomberek 4y ago
    As we make flakes stable, this will improve as the docs can prioritize this information, and tooling can focus on making this more clear. On a much longer horizon, future Nix language (eg: Nickel) improvements provide a gradual typing system. On a short-term, I'm trying to provide some opinionation and a framework to describe this (https://floxdev.com/docs/custom-packages/ https://floxdev.com/docs/custom-packages/) . The challenge is to provide enough simplicity, but not so much that one loses the very benefits we are trying to achieve.
    - eximius 4y ago
      Why does it need to be gradually typed? If there was the equivalent to Rust doc generation that said `fn configuration(config: Config, pkgs: Packages) -> Configuration` "Implement this function in `/etc/nixos/configuration.nix" And then I could click into each type and see what it's supposed to be, etc. Now, there would be some differences because Rust can't have arbitrary record types but you can imagine either forcing packages to define their inputs or just take the idea of rust doc here as a visual example. But being able to progressively drill down the types - and have the types checked by the language runtime! - would massively improve Nix's ease of use and discoverability.
      - pxc 4y ago
        > Why does it need to be gradually typed? Because one of the things that's nice about using Nix as a consumer of Nix libraries is that for simple use cases, your code can be so simple that it truly resembles a plain configuration file. By implementing a gradual type system, Nickel allows producers of Nickel libraries to enrich their code with helpful type annotations without making all of the code consuming those libraries verbose or cumbersome. > being able to progressively drill down the types - and have the types checked by the language runtime! - would massively improve Nix's ease of use and discoverability. That definitely seems to be the goal. If you wanna get a feel for how Nickel looks today, you should try translating the exercises from the old Tour of Nix¹ on the new Nickel Playground²! The lead dev is very friendly and receives feedback warmly. 1: https://nixcloud.io/tour/?id=1 https://nixcloud.io/tour/?id=1 2: https://nickel-lang.org/playground https://nickel-lang.org/playground

schemescape 4y ago

Did you mention Guile because of Guix? If not, you might be interested in GNU Guix.

Ericson2314 4y ago

https://github.com/NixOS/rfcs/pull/136 https://github.com/NixOS/rfcs/pull/136 soon, you shouldn't have to care what language it uses!