5 ms·

It's been a while since I used NixOS, but I never really had an issue with the language. What was frustrating was in package solutions there were all these spec

It's been a while since I used NixOS, but I never really had an issue with the language. What was frustrating was in package solutions there were all these special functions which as far as I can tell were undocumented and I couldn't figure out what they could do. So there was sort of this gap in terms of documentation between theoretical understanding and tooling/functional understanding which I struggled to cross.

mplanchard 5y ago
The best way I’ve found around this is to always keep a local clone of nixpkgs so that I can grep for where functions are defined and hope like hell that there are some comments in the vicinity. Definitely not ideal.
- rgoulter 5y ago
  If you're using Nix on your system, you can also find nixpkgs symlinked under ~/.nix-defexpr/channels/nixpkgs/pkgs/ or so.
  - mplanchard 5y ago
    Nice, I did not know this. Thanks!
  - Filligree 5y ago
    And if you have flakes and nix-command enabled, you can run `nix edit nixpkgs#lib.sort` to get the definition of the sort function. (This will just tell you it's imported from lists. `nix edit nixpkgs#lib.lists.sort` will get you the actual definition.)
snowytrees 5y ago
100% this. The language is designed for its use case which is packaging and configuration (nothing more or less). It has a learning curve due to being lazy and functional but works great once you get the hang of it. But the documentation of all its functions is so annoying. You have builtins and the nixpkgs functions[1]. There is learning the language, and then learning how to use it. Then there is the entire ecosystem of custom packaging functions that have their own pros/cons [2]. The issue isn’t with the language but the difficulty with trying to make existing tooling work the Nix way. That part is where I agree with the curse of nix. But the effort is worth it because once the packaging is complete it just works (forever). 1: Best resource I’ve found is this: https://teu5us.github.io/nix-lib.html https://teu5us.github.io/nix-lib.html 2: The status of lang2nix: https://discourse.nixos.org/t/status-of-lang2nix-approaches/ https://discourse.nixos.org/t/status-of-lang2nix-approaches/...
- zeec123 5y ago
  However, until this works, nixpkgs should provide a wrapper around FHSUserEnv which allows developers to develop without the curse.
  - kristjansson 5y ago
    Convenient (version-addressed!) FHSUserEnv is exactly what I want out of Nix. Land me in an environment that has a list of deps (at specific versions, not hashes!), let me go mess with it.
- jcranberry 5y ago
  These look pretty promising. Maybe I'll give nixOS another shot because I really was a big fan.
mikepurvis 5y ago
As someone 8 months into a major Nix packaging effort (1200 package definitions, mostly auto-generated), this is 1000% the most significant issue. Reading the pills can get you the first little bit, like the difference between derivation and mkDerivation, but so much later stuff is just completely undiscoverable and inconsistent, like the fact that overrideAttrs may subtly not do what you want if it's a Python package since you have to use overridePythonAttrs instead, but the corresponding function for other builders (eg overrideBazelAttrs) doesn't exist.
- FRidh 5y ago
  This is indeed not very good. Note there is a reason that overridePythonAttrs exists: it overrides the call to buildPythonPackage instead of mkDerivation. There is/was an RFC on standardizing overriding in Nixpkgs but it got stuck. I think for these things to improve what is really necessary is funding to improve Nixpkgs. These kind of issues are fairly hard to solve as they span multiple ecosystems and require coordination.
  - mikepurvis 5y ago
    Oh, of course, and in my case it was an important discovery, because my custom packages were all also defined in terms of my own mkDerivation-wrapping function, so I happily copy-pasted the definition of overridePythonAttrs to make my own overrideMyAttrs version of it. But it was brutal that I had to just stumble across this. I think the article correctly identifies that there is decent enough documentation in Nix for: - Beginners to the nix language/concept (Nix Pills) - Beginner users of NixOS (the NixOS manual) - Beginners to packaging for Nix (wiki articles, blogs) But there is a huge, huge gap for the user who is trying to cross the chasm and become a true expert in it all— who wants to understand at a deep level things like how overlays and namespaces work, how bootstrapping works and what is the division of responsibilities between nix and nixpkgs, plus the inner workings of things like buildEnv and stdenv.
    - JamesSwift 5y ago
      I mentioned it already below, but just to emphasize: I think Burke Libbeys playlist on Nix [1] is that missing piece. It lays down a solid foundation of understanding on what Nix is both conceptually and syntactically. You are then able to derive the rest of the needed understanding by clicking through the nix source of whatever it is you are trying to figure out. [1] - https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4...
zeec123 5y ago
Fully agree. It is not the language, but the functions around nixpkgs.
zeec123 5y ago
What really helped me were the videos of Jon Ringer: https://www.youtube.com/user/elitespartan117j27 https://www.youtube.com/user/elitespartan117j27
- jonringer117 5y ago
  Glad someone found them useful :)
  - zeec123 5y ago
    I cannot thank you enough for these. It is so much useful to see someone doing a task.
takeda 5y ago
I believe what Nix really, really needs. Is to separate all the lib, builders and frameworks for languages need to be separated out of it (probably into separate repo, maybe even repos), and treat it like a stdlib is treated in any other language. That means, it can't be just modified by anyone on a whim, all of changes need to be done through proper RFC mechanism. And anything in it must be documented. Having all that done would greatly improve learning time, it would probably make it easier to maintain other packages as well. It made sense that it was done this way originally, because initially no one knows what would be needed, but right now many things are solidified and don't change that much.

mplanchard 5y ago

The best way I’ve found around this is to always keep a local clone of nixpkgs so that I can grep for where functions are defined and hope like hell that there are some comments in the vicinity. Definitely not ideal.

rgoulter 5y ago
If you're using Nix on your system, you can also find nixpkgs symlinked under ~/.nix-defexpr/channels/nixpkgs/pkgs/ or so.
- mplanchard 5y ago
  Nice, I did not know this. Thanks!
- Filligree 5y ago
  And if you have flakes and nix-command enabled, you can run `nix edit nixpkgs#lib.sort` to get the definition of the sort function. (This will just tell you it's imported from lists. `nix edit nixpkgs#lib.lists.sort` will get you the actual definition.)

snowytrees 5y ago

100% this. The language is designed for its use case which is packaging and configuration (nothing more or less). It has a learning curve due to being lazy and functional but works great once you get the hang of it. But the documentation of all its functions is so annoying. You have builtins and the nixpkgs functions[1]. There is learning the language, and then learning how to use it. Then there is the entire ecosystem of custom packaging functions that have their own pros/cons [2]. The issue isn’t with the language but the difficulty with trying to make existing tooling work the Nix way. That part is where I agree with the curse of nix. But the effort is worth it because once the packaging is complete it just works (forever). 1: Best resource I’ve found is this: https://teu5us.github.io/nix-lib.html https://teu5us.github.io/nix-lib.html 2: The status of lang2nix: https://discourse.nixos.org/t/status-of-lang2nix-approaches/ https://discourse.nixos.org/t/status-of-lang2nix-approaches/...

zeec123 5y ago
However, until this works, nixpkgs should provide a wrapper around FHSUserEnv which allows developers to develop without the curse.
- kristjansson 5y ago
  Convenient (version-addressed!) FHSUserEnv is exactly what I want out of Nix. Land me in an environment that has a list of deps (at specific versions, not hashes!), let me go mess with it.
jcranberry 5y ago
These look pretty promising. Maybe I'll give nixOS another shot because I really was a big fan.

mikepurvis 5y ago

As someone 8 months into a major Nix packaging effort (1200 package definitions, mostly auto-generated), this is 1000% the most significant issue. Reading the pills can get you the first little bit, like the difference between derivation and mkDerivation, but so much later stuff is just completely undiscoverable and inconsistent, like the fact that overrideAttrs may subtly not do what you want if it's a Python package since you have to use overridePythonAttrs instead, but the corresponding function for other builders (eg overrideBazelAttrs) doesn't exist.

FRidh 5y ago
This is indeed not very good. Note there is a reason that overridePythonAttrs exists: it overrides the call to buildPythonPackage instead of mkDerivation. There is/was an RFC on standardizing overriding in Nixpkgs but it got stuck. I think for these things to improve what is really necessary is funding to improve Nixpkgs. These kind of issues are fairly hard to solve as they span multiple ecosystems and require coordination.
- mikepurvis 5y ago
  Oh, of course, and in my case it was an important discovery, because my custom packages were all also defined in terms of my own mkDerivation-wrapping function, so I happily copy-pasted the definition of overridePythonAttrs to make my own overrideMyAttrs version of it. But it was brutal that I had to just stumble across this. I think the article correctly identifies that there is decent enough documentation in Nix for: - Beginners to the nix language/concept (Nix Pills) - Beginner users of NixOS (the NixOS manual) - Beginners to packaging for Nix (wiki articles, blogs) But there is a huge, huge gap for the user who is trying to cross the chasm and become a true expert in it all— who wants to understand at a deep level things like how overlays and namespaces work, how bootstrapping works and what is the division of responsibilities between nix and nixpkgs, plus the inner workings of things like buildEnv and stdenv.
  - JamesSwift 5y ago
    I mentioned it already below, but just to emphasize: I think Burke Libbeys playlist on Nix [1] is that missing piece. It lays down a solid foundation of understanding on what Nix is both conceptually and syntactically. You are then able to derive the rest of the needed understanding by clicking through the nix source of whatever it is you are trying to figure out. [1] - https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4...

zeec123 5y ago

Fully agree. It is not the language, but the functions around nixpkgs.

zeec123 5y ago

What really helped me were the videos of Jon Ringer: https://www.youtube.com/user/elitespartan117j27 https://www.youtube.com/user/elitespartan117j27

jonringer117 5y ago
Glad someone found them useful :)
- zeec123 5y ago
  I cannot thank you enough for these. It is so much useful to see someone doing a task.

takeda 5y ago

I believe what Nix really, really needs. Is to separate all the lib, builders and frameworks for languages need to be separated out of it (probably into separate repo, maybe even repos), and treat it like a stdlib is treated in any other language. That means, it can't be just modified by anyone on a whim, all of changes need to be done through proper RFC mechanism. And anything in it must be documented. Having all that done would greatly improve learning time, it would probably make it easier to maintain other packages as well. It made sense that it was done this way originally, because initially no one knows what would be needed, but right now many things are solidified and don't change that much.