5 ms·

I think one way to look at nix is that it want to act(in good way) the central source of truth for deterministic package, and one way it goes about it is by doi

I think one way to look at nix is that it want to act(in good way) the central source of truth for deterministic package, and one way it goes about it is by doing the step for both system level packages, and language level packages(for example, if you approach a nodejs app, you will lock both the nodejs version, the underlying openssl or other headers lib used by node-gyp, and the node_module packages itself in nix) and that is one of the main flow of nix, take a existing project/app/software, and convert it to usable nix packages, and that work even in edge cases like: - app that is binary , so you can't build it from source, but is using dynamic libraries, then you can use autoPatchelfHook to tell nix to patch the binary to swap out the libraries to nix's version - app that uses a lot of hard coded file system path that you would prefer not to patch them all out, then you can use buildFHSUserEnv to package/run the application/package in full FHS-compatible scenario but the main point is that, nix is extreme in its approach, and the best approach in my opinion, is to do swapping step by step, ex: you want to convert a existing project to nix, lets say nodejs - you add the main deps in the default.nix (nodejs, yarn, high level utility needed to build) - use sandBox false to allow building the app with yarn/npm in internet accessible(by default nix uses sandBox which disallow internet inside build step, which causes issue like npm install not working, etc) - confirm working, then start using tool likes yarn2nix, other similar, and convert the packages itself to a usable set of nix packages though I do agree that nix have the knowledge bias issue, and alot of my learning of nix involve me looking at the nixpkg sources itself and sometime even the nix's code

throwaway894345 6y ago
The trouble is that it's not just that nix is opinionated, it's that much of the complexity is in patterns and conventions that are implemented in nix. Learning everything about everything about the Nix toolchain is only one third of the battle; the rest is learning all of the conventions and patterns for writing Nix expressions, and these conventions and patterns are subject to variance between target languages. This is made terribly difficult because the language is dynamically typed and it's almost impossible to know about the "shape" of any given parameter because there is no way to know where it is defined in the enormous nixpkgs repo except to grep around and try to find the place where the caller is invoked, what is passed into it, and trace that back to an original import statement (and from there to a file on disk and the corresponding definition). That long tedious process is the hot path for developing in Nix.
- yjftsjthsd-h 6y ago
  Very much agreed; nix is its own world, which makes it really hard to get into. I wish someone had written "nix but in python" (or bash, or whatever) that still used a nix-store equivalent, kept the overall design and the immutable and reproducible packaging, still connected everything by hash, did all the hydra-style build infrastructure.. but didn't use nix-the-language, and made an explicit effort to use more conventional language wherever reasonably possible. Ideally, it'd even let you write expressions in arbitrary languages; it should be perfectly possible to say, "here is a directory containing 'inputs' and 'output' subdirectories based on your declared dependencies; place any build steps you want in build.sh, so long as they deterministically populate 'output' from the package directories in 'inputs'" (and then run the build a few times, without network access, to make sure). I don't see anything in nix that actually needs nix-the-language, or even a functional language at all, and I think nix-the-package-manager would be far more accessible if they'd not tied nix-the-language to everything.
  - chpatrick 6y ago
    I think functional languages are a good fit for the problem though. Given some input, compute a static build plan. It's very rare that you need to do imperative-style computation for that. What I think Nix really needs is some kind of static typing, because right now if you make a type error the error might appear in a completely random location, making it difficult to debug.
    - throwaway894345 6y ago
      I don't think this is any more true for this problem space than other problem spaces. The "pure functional package manager" property doesn't come from the functional expression language, but from the thing that takes the static build plan and executes it. You could make these build plans in Python (or Starlark https://go.starlark.net https://go.starlark.net) very elegantly and with the massive added bonus that they are intelligible to a much broader audience, and Python still allows for a very functional style. The only caveat I would add is that the Nix expression language has really nice support for multiline strings and Python still hasn't figured that out. Lastly, Python also supports type annotations and even a type checker (although the type checker leaves a lot to be desired, such as basic types or callbacks that take kwargs so it might be better off to implement one's own type checker). But 100% agreement that Nix needs a type checker!

throwaway894345 6y ago

The trouble is that it's not just that nix is opinionated, it's that much of the complexity is in patterns and conventions that are implemented in nix. Learning everything about everything about the Nix toolchain is only one third of the battle; the rest is learning all of the conventions and patterns for writing Nix expressions, and these conventions and patterns are subject to variance between target languages. This is made terribly difficult because the language is dynamically typed and it's almost impossible to know about the "shape" of any given parameter because there is no way to know where it is defined in the enormous nixpkgs repo except to grep around and try to find the place where the caller is invoked, what is passed into it, and trace that back to an original import statement (and from there to a file on disk and the corresponding definition). That long tedious process is the hot path for developing in Nix.

yjftsjthsd-h 6y ago
Very much agreed; nix is its own world, which makes it really hard to get into. I wish someone had written "nix but in python" (or bash, or whatever) that still used a nix-store equivalent, kept the overall design and the immutable and reproducible packaging, still connected everything by hash, did all the hydra-style build infrastructure.. but didn't use nix-the-language, and made an explicit effort to use more conventional language wherever reasonably possible. Ideally, it'd even let you write expressions in arbitrary languages; it should be perfectly possible to say, "here is a directory containing 'inputs' and 'output' subdirectories based on your declared dependencies; place any build steps you want in build.sh, so long as they deterministically populate 'output' from the package directories in 'inputs'" (and then run the build a few times, without network access, to make sure). I don't see anything in nix that actually needs nix-the-language, or even a functional language at all, and I think nix-the-package-manager would be far more accessible if they'd not tied nix-the-language to everything.
- chpatrick 6y ago
  I think functional languages are a good fit for the problem though. Given some input, compute a static build plan. It's very rare that you need to do imperative-style computation for that. What I think Nix really needs is some kind of static typing, because right now if you make a type error the error might appear in a completely random location, making it difficult to debug.
  - throwaway894345 6y ago
    I don't think this is any more true for this problem space than other problem spaces. The "pure functional package manager" property doesn't come from the functional expression language, but from the thing that takes the static build plan and executes it. You could make these build plans in Python (or Starlark https://go.starlark.net https://go.starlark.net) very elegantly and with the massive added bonus that they are intelligible to a much broader audience, and Python still allows for a very functional style. The only caveat I would add is that the Nix expression language has really nice support for multiline strings and Python still hasn't figured that out. Lastly, Python also supports type annotations and even a type checker (although the type checker leaves a lot to be desired, such as basic types or callbacks that take kwargs so it might be better off to implement one's own type checker). But 100% agreement that Nix needs a type checker!