1. 86
  1. 19

    This certainly puts a lot more weight behind https://lobste.rs/s/d0lh6w/we_want_make_nix_better, which, in typical lobste.rs fashion, was shot dead on arrival by a small subset of its userbase.

    1. 31

      Riff would’ve made an excellent first post.

      1. 4

        “small subset” yet it has over 20 flags. That’s a lot of engagement in my experience here.

        1. 1

          I’m pretty sure that any group of Lobsters users is still a small subset of Nix’s user base. 🙂

          1. 5

            Sure, but that’s not the takeaway from the parent commenter. “in typical lobste.rs fashion, was shot dead on arrival by a small subset of [lobst.er’s] userbase”

      2. 8

        Got curious how the

        determined which external dependencies are necessary based on your crate dependency graph,

        step works. Historically, there were some ambitions to declaratively declare native build inputs in Cargo.toml, but that didn’t go far, and so each crate using system dependencies is a unique snowflake. So, determining this is a bit hard, and indeed it seems that the solution here is to basically hard-code deps:


        Which is great! If this hard coded just OpenSSL, I bet that would still solve 80% of cases for me :-)

        1. 9

          The registry exists to bootstrap the utility of Riff. Long term, it is our goal that projects define their own metadata so the registry is no longer used or necessary: https://github.com/determinateSystems/riff#how-to-declare-package-inputs

          1. 3

            Notably, openssl is one of the few entries with both a build-inputs and a targets section

          2. 4

            Great, so, now I just need to install Nix successfully on macOS…

            1. 2

              Try riff cargo install nix ;)

              1. 1

                Have you been having issues with the install script recently? It’s been quite stable for me on macOS for the past year or so.

                1. 1

                  The last time I tried it was probably 8 months ago or so. It broke to the point where I couldn’t uninstall and reinstall it fresh. I’m on an older macOS version, which could be part of the problem.

                  1. 2

                    Specific issue number? macos version?

                    1. 1

                      Ehh, I was probably too lazy to open an issue. Or maybe there already was one. I don’t remember. I’ll revisit it at some point.

                      1. 6

                        You’ll have to follow the uninstall instructions before reinstalling it: https://nixos.org/manual/nix/stable/installation/installing-binary.html#macos.

                        If I had to guess, these may not have been up to date in the official docs yet when you ran into trouble.

                        Feel free to message me if you still have trouble.

                        1. 2

                          Thanks, that did the trick.

                  2. 1

                    yes, the installation script works fine and dandy… but all of my mac-using coworkers have to reinstate the changes to /etc/zshrc (that sources the nix-daemon.sh) on every macos update now. there is an open issue on the github repo.

                    from what I have seen, installing is very reliable and very easy. updating your mac, though, causes nix to lose it’s mind every time.

                    1. 3

                      I wouldn’t really say nix is losing its mind.

                      Apple is leaving zshrc editable but then treating it like their property (and for some reason not using the mechanism they made to place a new system default bashrc in the relocated items folder on update). Your coworkers could use bash (or set up another shell–though they’d have to do that manually) to skirt the problem. The update doesn’t affect nix itself.

                      (I realize this isn’t a satisfying workaround to anyone who wants to use zsh, but if they are just using the default shell they may not have an opinion…)

                      I’ve been trying to get Apple’s attention on this. (I am finally in touch with someone in developer relations, but haven’t gotten a response…)

                      1. 1

                        you’re right, I’m exaggerating… but I support whatever shell the devs want to use. I use bash and I’m happy with it (I would probably change it from zsh on mac), but other people use whatever it is that they like and are productive using.

                        that seems like a somewhat serious flaw (oversight?) in the OS that bash will save it’s configuration between updates but not zsh. If you do hear from anyone, I would be interested to hear what they have to say on the matter. Maybe there is a Proper Reason that changes are reset on each update?

                      2. 2

                        Yep, that’s the issue nowadays. IIRC you can source it from ~/.zshrc and not have to worry about it though

                        1. 1

                          So the question with that suggestion is: what about all of the build users? Single-user installations are not supported on arm64 macs, so all 32 of those build users also won’t be able to have nix in their path, either. Is that a problem in practice? (I don’t have a mac right now, I can’t answer that question)

                          I also tried putting it into /etc/zshenv, and that kind-of worked… but the developer also had rbenv installed and somehow it was being loaded after everything else, so even though direnv loaded the nix environment, the $PATH had the “wrong” ruby from rbenv instead of nix.

                          1. 2

                            The build users don’t need Nix in the path. The build users is an implementation detail of process isolation, and their specific shell / environment is immaterial because Nix manages it.

                        2. 1

                          For what it is worth, I tested an update to Ventura and the Nix installation remained properly configured in the zshrc through the upgrade. It sounds like abathur might have reached the right people.

                          1. 1

                            I think I did, but I doubt it was early enough to have affected this yet–I did bug them again and got an initial response yesterday.

                    2. 2

                      We’re anxious to continue solving thorny, un-fun problems for developers

                      That sounds like… fun? ;)

                      On a more serious note: I see several projects popping up using Nix under the hood, with the explicit intention of hiding it away from users. I wonder if this means that people have given up on Nix ever becoming more ergonomic, and if these kind of projects actually undermine that kind of effort.

                      It’s as if git UI tools had become more mainstream instead of git becoming more usable/people just swallowing the complexity. Would we be better off in the end?

                      1. 12

                        Eelco and I haven’t cofounded DetSys together to hide Nix away. We’re looking at a major problem of Nix’s onboarding process being a bit of a slog, and we’re looking at ways to get people value from Nix as a taste. We see a glorious future for Nix, but to bring it to light we’re trying to meet potential future users where they are.

                        There definitely are companies and projects trying to use Nix as part of their product, and don’t have much interest in it being about Nix. Eelco and I aren’t doing that.

                      2. 1

                        Well, Determinate has delivered on the big announcement. A very annoying problem they may have solved here.

                        1. 1

                          It would be awesome if you could also do riff cargo install <crate> and it would do same for cli tools. I have an experimental cli crate I made a couple of years ago that requires some external dependencies. I’m not even sure if that makes any sense as I haven’t touched rust in a couple years and sorta forgot how the cargo infrastructure works.

                          1. 1

                            The article mentions Rust and libiconv. What are the use cases? I.e. what’s in practice not solved by crates written in Rust? (Obviously, libiconv supports more things, hence “in prctice”.)

                            1. 7

                              If you take a brand new Mac and install Rust, 400 out of the top 2,000 crates will compile successfully. Add Riff, and you’re up to 1,650 passing builds. I don’t have specific numbers for Ubuntu or other Linuxes.