3 ms·

> So in some sense the language is a decent filter for people who won't like the inevitable rest anyways. I'm not saying i'd like to package complex systems wi

> So in some sense the language is a decent filter for people who won't like the inevitable rest anyways. I'm not saying i'd like to package complex systems with nix/guix, but i certainly would use them more to package my own projects if the ecosystem had better docs and error messages in regards to typing/syntax. I'm ready to carefully read through a 20 pages manual if that's what it takes, but i personally find the documentation and diagnostics of both projects to be sub-par compared to my expectations (looks really clear on paper, now why doesn't my declaration work?). Granted, i'm not a skilled engineer so maybe i'm not your target audience, but i believe as an amateur programmer/sysadmin i'm part of the target audience to package anything i find useful and/or my own programs.

Ericson2314 5y ago
Yes, we should have types! Yes, we should have better docs! (I think we have a bad mix of authoritative reference and tutorial that fails on both counts.) But if you want types, I daresay you are already understanding the basics of how the functional language works :). I imagine your problems are less: wtf is: ((x: x x) (y: y y)) and more: wtf is stdenv, wtf is mkDerivation, wtf is a setup hook, why are othre build systems hacks on top of the autotools defaults, and not clean alternatives? etc. etc.
- southerntofu 5y ago
  > wtf is: ((x: x x) (y: y y)) Well to be fair i don't understand this syntax. But i guess i should be able to learn it in under one page of docs. > wtf is stdenv, wtf is mkDerivation, wtf is a setup hook, why are othre build systems hacks on top of the autotools defaults, and not clean alternatives? etc. etc. But yes my problem is that i don't have a list of standard options and their types so i end up doing copy-pasta of what works in another package and adjust until it works. On a higher level, i've found it harder than expected to turn an existing package declaration from nixOS into a source-provided build file to try and build a specific branch. Or to use an existing NixOS declaration to build a reproducible (and installable) liveUSB as there seems to be various tools doing this job but i couldn't get any of them to build successfully. I'm interested if you have good learning resources to share!

Ericson2314 5y ago

Yes, we should have types! Yes, we should have better docs! (I think we have a bad mix of authoritative reference and tutorial that fails on both counts.) But if you want types, I daresay you are already understanding the basics of how the functional language works :). I imagine your problems are less: wtf is: ((x: x x) (y: y y)) and more: wtf is stdenv, wtf is mkDerivation, wtf is a setup hook, why are othre build systems hacks on top of the autotools defaults, and not clean alternatives? etc. etc.

southerntofu 5y ago
> wtf is: ((x: x x) (y: y y)) Well to be fair i don't understand this syntax. But i guess i should be able to learn it in under one page of docs. > wtf is stdenv, wtf is mkDerivation, wtf is a setup hook, why are othre build systems hacks on top of the autotools defaults, and not clean alternatives? etc. etc. But yes my problem is that i don't have a list of standard options and their types so i end up doing copy-pasta of what works in another package and adjust until it works. On a higher level, i've found it harder than expected to turn an existing package declaration from nixOS into a source-provided build file to try and build a specific branch. Or to use an existing NixOS declaration to build a reproducible (and installable) liveUSB as there seems to be various tools doing this job but i couldn't get any of them to build successfully. I'm interested if you have good learning resources to share!