[Shoue]

> - Can't build with nix-build. After long time searching it seems like you're supposed to run nix-build -E 'with import <nixpkgs> {}; callPackage ./default.nix {}' - shouldn't there be a simpler way for this common case?

This is because the default.nix you have is exporting a lambda that expects arguments to be saturated, `callPackage` does this for you automagically hence why you have to use it.

Instead you probably want the nixpkgs import line _inside_ default.nix, either in a let-in binding or using the `?` operator to default a lambda argument to something, usually nixpkgs itself bound to a `pkgs` argument so you can use `pkgs`[0].

Even better, you can use Niv to pin nixpkgs to a specific nixpkgs commit so that it doesn't change as you update your system's nixpkgs channel with the `nix-channel` command because `<nixpkgs>` is special syntax referring to what's stored in your $NIX_PATH[1].

[0]: see the default argument section: https://nixos.wiki/wiki/Nix_Expression_Language [1]: https://nixos.org/guides/nix-pills/nix-search-paths.html

[pmarreck]

You provided what is probably a logical explanation but didn't answer the question in the way he meant it (I think), which is: Addressing common use-cases should be a simple matter. Addressing complex use-cases should ALSO be a simple matter ideally, but is permitted to be a complex matter. Here we have a case where a common use-case is addressed by a complex-seeming solution (unless you are essentially "degreed" in Nix, apparently, and understand exactly why partial function application won't work here or whatever). Or are you saying he's actually doing it wrong and built the nix file wrong?

I'm about to dive headfirst into this nix business and this is intimidating, lol

[soraminazuki]

> Addressing common use-cases should be a simple matter.

Fully agree, but the given example isn't such a case but rather incorrect code.

The example is somewhat akin to writing the following Python code and expecting it to print "hello".

    def main():
        print 'hello'

It wouldn't work because you need to call the main function. It's not a problem of Python not addressing common use cases.

[BoardsOfCanada]

You're right but just to explain where I came from there were a lot of "just use this default.nix" that had arguments and could not "just be used".

I understood that an argument was needed, that error was clear and when I googled it I found the solution that I wrote.

I supposed it's meant to plug in to something bigger maybe and that's why there are arguments without import everywhere.. maybe? But I've given up now, so I'll never know, we're just gonna suck it up and keep using brew and try to make it idiot-proof somehow.

It just feels like a shame that nix is so unapproachable. It's just as much apple's fault though - if xcode has some open command line tools I'm sure there would have been ready-made formulas for everything we needed. At least I got to vent.

[soraminazuki]

You might want to read "Nix Pills" if you ever want to look into Nix again. It's the best introductory material for Nix that I'm aware of, and it gave me a better picture of the basics required to get comfortable with Nix.

It's on the NixOS website, but IMO it's worth making it more visible to newcomers:

https://nixos.org/guides/nix-pills/

From my experience, it became considerably more easier to figure out or search for solutions once I've grasped the basics from "Nix Pills." Once I became comfortable enough, I also relied heavily on the Nixpkgs repository[1] as a great source of information. It has an approachable codebase and some quick grepping gave me many examples when trying to figure out how to write packages for a particular language.

[1]: https://github.com/NixOS/nixpkgs

[Ericson2314]

> You're right but just to explain where I came from there were a lot of "just use this default.nix" that had arguments and could not "just be used".

> I understood that an argument was needed, that error was clear and when I googled it I found the solution that I wrote.

So in this case the advise was worst than useless? Had you been figuring things out on your own, would it have been less bad?

> It's just as much apple's fault though - if xcode has some open command line tools I'm sure there would have been ready-made formulas for everything we needed.

Yes that is too true. Keeping things working with apple is so draining it's hard to have energy left over to do other things right.