81–90 of 204 posts
Earlier quoted context omitted.
> Something like `nix-shell --dry-run`? Exactly that? Lol :)
Really? It is not written in the official nix-shell manual https://nixos.org/manual/nix/stable/command-ref/nix-shell.ht... I still will try when I get to my macbook. Thank you!
Beside being invasive on MacOS, as said by @ridiculous_fish, it took me more than 3 hours (and it didn't yet finish, I just quit all) to use QMK. I just cloned the Github repository of QMK and did `nix-shell` as they provide shell.nix file. 1. Does every nix-shell require building the whole world from ground-up? Seems impractical to me. 2. What is the right approach? This is not to bash Nixpkgs, because I installed N…
MacOS has issues with binary cache because of apple's requirement on where macOS can be run.
With Eelco as a cofounder of DetSys, I feel really excited about where we're going here. I think the world is in many ways primed and ready for Nix, as long as we can help Nix "meet them in the middle." We're working on making Nix more accessible and producing good and usable, production-ready workflows so teams can just pick it up and go. I'd love to hear what y'all think, to help make sure we're going in the right…
Look at this:
https://nixos.wiki/wiki/PostgreSQL
Now, the real "workflow" with nix is look at other setups, or just look at the code:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/s...
And look at the code is the only reliable way to see what exactly is supported.
My second gripe is the fact is hard to see what nix do. Today I hit this trouble:
https://www.reddit.com/r/NixOS/comments/x46w98/why_new_user_...
The thing is: Nixos not tell what is doing. `verbose` is too much noise.
What I wish now is something like:
nix change nothing (if my changes somehow don't do anything, like in my issue)
nix setup users...
nix setup postgresqlWriting the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning…
This is a pattern I've seen over and over: if a project tries to do something different, the novel aspect gets blamed for issues that would not be surprising in any other context. When faced with a massive awful codebase in Java, well, sometimes legacy code can be a pain, right? It is what it is. People rarely jump to "OOP is a mistake" or "Java is completely unusable". But that's exactly what happens all the time with, say, functional programming.
Pointing to an uncommon choice as the underlying cause of a problem makes for a nice, pat story; the pervasive, diffuse problems inherent to messy legacy code do not. After all, here's a single thing that, presumably we can actually change! Nix being functional is an objective fact while people can—reasonably or not—disagree on how well-designed and well-written Nixpkgs-the-codebase is. Besides, even if we could agree, what could we do about it? We all know how much momentum legacy code has and how hard it is to make anything beyond local improvements. Being a socially convenient story doesn't mean it's a particularly strong explanation, but it does mean that people will believe it even if it isn't.
Hot take as a NixOS user that uses Nix for work: "all" we need is a much better, sound, statically typed language to build better abstractions with. The only hard requirements I can think of are algebraic data types with exhaustive pattern matching to go with, row polymorphism, purity and good inline documentation support. I don't know if a good enough hostable language exists or if it should be a new version of Nixl…
I'm considering Nix but don't like the custom language. I wish Guix were. more popular and less extreme on the freedom side. Chances are I'll just do a fresh Arch install or maybe try Debian rolling.
These days I like to install almost all software and libraries by hand in my home directory. All I really want is a solid system that basically boots fresh then loads my home directory. Maybe I should do a net boot of some sort?
Any other suggestions?
Writing the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning…
> To seriously answer the question: is the Nix language required for the Nix packaging system to exist? Laziness is required, to some degree, but can the next iteration provide an on-ramp which doesn't involve learning a new lang and paradigm? Guix folks sure think so. I'd love to hear from someone deeply familiar with Nix and Guix about laziness. I'm deeply familiar with Nix and I've concluded that lazy semantics is…
Writing the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning…
Yup. I can't even imagine what could I accomplish if I'd have something like a "python library" for nixpkgs. I still use nixos but gave up fiddling with nix for a while, after trying to wrap some stuff I am using/developing.*
* (Yes, I know it's easy. I just need flakes or correct amount of "lib: prev: { self"s. Sadly not for me.)
Earlier quoted context omitted.
I might suggest making a typed superset of Nix, basically adding record types and function signatures. That in itself would be a huge boon for tooling and interacting with nixpkgs. nixpkgs describes a huge and varied meta-API for derivations in various build ecosystems, which makes it hard to use because you ultimately need to dive into source code.
We've heard this feedback pretty frequently. We have a few ideas of ways to add some types to Nix in place. I think even simple naive approaches would add a lot of safety and improve the usability of Nix. However, one of the bigger problems here is the general API design of Nixpkgs. Most of the function interfaces use some named parameters and then use `...` to accept any additional parameters. All of those then get…