Closed heinwol closed 10 months ago
Thank you for the reply! But may I ask, why do you want to pin nixpkgs version in flakes? It can be done, but the sole purpose of flake.lock is to, well, pin inputs versions. Or do you need a specific version of nixpkgs? If so, then why is that, I wonder? Is deno so unstable?
And the second one: if not nixpkgs-fmt, how do you format your code?
But may I ask, why do you want to pin nixpkgs version in flakes? It can be done, but the sole purpose of flake.lock is to, well, pin inputs versions
Youre right, thanks for reminding me about the lock. I usually only use stable features so I'm still a bit slow on flakes. And to be fair I really should've known better cause I've done plenty of reading and messing around with flakes. I guess it's just a knee-jerk reaction for me to pin stuff down.
Also yeah Deno 1.0 is very stable. I am using the --unstable flag but in this case it's more like --beta than unstable (they haven't perfected compilation). Deno 2.0 will definitely break this project though.
nixpkgs-fmt, how do you format your code?
For most languages I use a standard formatter, and just deal with not liking the choices. I'm only really particular about nix because I find I really struggle to read/understand code formatted with nix-fmt (and sadly all the other nix formatters I could find have the same problem).
I'm only half done writing my own formatter, so right now it's done manually. The principles are really simple, and similar to python black with line-width set to 1 if you've ever used that. I would like to always follow my own rules (like I agree with adding spaces around the =
) but it's difficult to be consistent without actually having an auto formatter.
So if you're curious my formatter has these choices; defaults to 4 indent, but maybe I'll change it to 2. Trailing commas for parameters (instead of "leading" comma style). Indents for code blocks whether it's function bodies, let in, attr sets, lists, if then else, etc. (e.g. I should've newlined and indented the url= near the top). Adding paraenthese around operations that have multi-line arguments (ex: ({ a=10;\n}.a)
or ({a=1;\n} // b)
). None of that is probably too controversial, but my last two choices probably are; 1. No with statements or inherit statements at all. 2. function calls with more than one argument (e.g. currying) get wrapped in paraenthese and each argument is on a newline.
Don't feel like you need to undo your changes though, I can handle the formatting.
Yet again, thanks for your work, I'm glad you liked what I did.
Regarding flakes: it's this state of software that is marked as experimental, but is de-facto more or less an established standard (not the only standard, but still). Flake opponents point out different caveats like necessity to specify all inputs in one place, bad integration with hydra, more boilerplate, less flexibility, etc, etc... But I find flakes really amusing and convenient. If that's not always true for you, I think it's still worth it to use them from time to time~
I use nix specifically to avoid bit-rot, which is why I avoid flakes since there's still the very real possibility of a breaking change. And actually I really hope there's a breaking change regarding needing-to-specify the system.
But yeah other than that I love flakes. I think the input/output design is really elegant, the lock file is awesome, standardization is awesome. The day that flakes become stable, I am going to switch absolutely all my stuff to flakes.
Oh and @heinwol speaking of flakes! I just added flakehub.com support to nvs! Try searching cowsay and it should show both the flake and non-flake options. Selecting a flake option also gives respective flake-instructions for the output
Thanks for the contribution! I can't believe it had an empty output. Something must've been wrong with my local tests.
There's a few changes I'd like to make
run/build_for_nix
After those changes, I'll get this merged.
And in the meantime I merged a commit for the empty output fix so that it's at least not broken