3 ms·

I've tried for a couple of days now to set up nix for reproducible iOS builds at work and I'm close to tears. - Examples that just don't work. - Commands that

I've tried for a couple of days now to set up nix for reproducible iOS builds at work and I'm close to tears. - Examples that just don't work. - Commands that run and no output is given, even though the text I'm following says it should output information I need. - Do I need nix-darwin? Well, the readme explains what it is: "Nix modules for darwin, /etc/nixos/configuration.nix for macOS." What? (Finally I found an answer at Stack overflow, and it seems I don't need it. Seems to be kind of NixOS on top of macOS) - 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? - An issue open since 2018 that the manuals simple example doesn't build: https://github.com/NixOS/nix/issues/2259 https://github.com/NixOS/nix/issues/2259 People chiming in years later that they only could build the example after reading the suggestions in that issue. - And now I can't start my nix-shell because it says there's a problem with SSL certificates. I'm giving up.

Shoue 5y ago
> - 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 https://nixos.wiki/wiki/Nix_Expression_Language [1]: https://nixos.org/guides/nix-pills/nix-search-paths.html https://nixos.org/guides/nix-pills/nix-search-paths.html
- pmarreck 5y ago
  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 5y ago
    > 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 5y ago
      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 5y ago
        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/ 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 https://github.com/NixOS/nixpkgs
rgoulter 5y ago
> 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? I think the StackOverflow post linked in the answer gives a good explanation: https://stackoverflow.com/questions/44088192/when-and-how-should-default-nix-shell-nix-and-release-nix-be-used https://stackoverflow.com/questions/44088192/when-and-how-sh... With other languages, e.g. with Haskell, you can run "stack build" and it will build the project.. or with C, you can run "cc *.c" and it will build an executable with main. -- Whereas, the `default.nix` example given in the tutorial is supposed to be given to callPackage. (The tutorial which provides the example instructs you to modify the all-packages.nix file in a clone of the nixpkgs repository). ...Which is unhelpful with the mindset of "I just want to write a Nix package for my thing", or just weird compared to what you'd expect from "Hello World". (But makes more sense in terms of "how to get started with nixpkgs"). The UX is much better with Nix Flakes. -- With flakes, there's a standard file format where you can run "nix build" and expect it to work.
- takeda 5y ago
  The problem is that default.nix is like setup.py for Python. It allowed people do all kinds of nonstandard things and custom code. The callPackage pattern was developed later on, and people who use it as some kind of standard, but it was just one more "standard", also cli tools never were update to accommodate is, so that's why the complicated string is used. The flakes are essentially supposed to standardize it: https://www.tweag.io/blog/2020-05-25-flakes/ https://www.tweag.io/blog/2020-05-25-flakes/ (well their goal is to fix other issues, but the standard format of the file fixes that problem too and CLI supports it as well)
ParetoOptimal 5y ago
What resources led you to try: default.nix (i'm guessing): derivation { name = "simple"; builder = "${bash}/bin/bash"; args = [ ./simple_builder.sh ]; inherit gcc coreutils; src = ./simple.c; system = builtins.currentSystem; } Command: nix-build -E 'with import <nixpkgs> {}; callPackage ./default.nix {}' Rather than something like this[0]: default.nix: with (import <nixpkgs> {}); derivation { name = "simple"; builder = "${bash}/bin/bash"; args = [ ./simple_builder.sh ]; inherit gcc coreutils; src = ./simple.c; system = builtins.currentSystem; } Which can be built with: nix build We should fix the docs that led your version rather than the second. 0: https://nixos.org/guides/nix-pills/working-derivation.html#idm140737320270416 https://nixos.org/guides/nix-pills/working-derivation.html#i...
- scintill76 5y ago
  I’m an intermediate Nix user - aren’t pkgs usually passed in as an argument so that the caller can choose them? I sort of accepted that verbose command line as a necessary evil of good design.
takeda 5y ago
> - Examples that just don't work. yes, the nixpkgs changes and some old articles might no longer be accurate :/ > - Commands that run and no output is given, even though the text I'm following says it should output information I need. could you give an example? > - Do I need nix-darwin? Well, the readme explains what it is: "Nix modules for darwin, /etc/nixos/configuration.nix for macOS." What? (Finally I found an answer at Stack overflow, and it seems I don't need it. Seems to be kind of NixOS on top of macOS) yes, you don't need it for what you described. nix-darwin is basically to provide configuration functionality of NixOS to your Mac. Nix-darwin is 3rd party product that's written in Nix for Nix. Similarly Home Manager. > - 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? a lot of people wrote about it. This is a convention that evolved from nixpkgs, it's still not officially supported by CLI tool (that's why the command looks so complicated, it's similar to calling `python -c "<whatever>`), seems like the default.nix file which is very similar in concept to setup.py (as you can put whatever you want inside) is being replaced by more stricter flakes.nix file. Which in a way brings some similarities to the callPackage convention. > - An issue open since 2018 that the manuals simple example doesn't build: https://github.com/NixOS/nix/issues/2259 https://github.com/NixOS/nix/issues/2259 People chiming in years later that they only could build the example after reading the suggestions in that issue. Because software evolves and old versions of file like to disappear with time. I run into this as well, although it was nix pills documentation. My solution was to simply get the new version of hello and use that. Although I agree, that's still unnecessarily confusing. I think a proper solution would be to host the file on the own server. Or even better, make a basic hello.c file and list its content in the doc. > - And now I can't start my nix-shell because it says there's a problem with SSL certificates. I'm giving up. You most likely uninstalled nss-cacert package. Perhaps `nix-env --rollback` would help.

Shoue 5y ago

> - 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 https://nixos.wiki/wiki/Nix_Expression_Language [1]: https://nixos.org/guides/nix-pills/nix-search-paths.html https://nixos.org/guides/nix-pills/nix-search-paths.html

pmarreck 5y ago
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 5y ago
  > 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 5y ago
    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 5y ago
      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/ 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 https://github.com/NixOS/nixpkgs

rgoulter 5y ago

> 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? I think the StackOverflow post linked in the answer gives a good explanation: https://stackoverflow.com/questions/44088192/when-and-how-should-default-nix-shell-nix-and-release-nix-be-used https://stackoverflow.com/questions/44088192/when-and-how-sh... With other languages, e.g. with Haskell, you can run "stack build" and it will build the project.. or with C, you can run "cc *.c" and it will build an executable with main. -- Whereas, the `default.nix` example given in the tutorial is supposed to be given to callPackage. (The tutorial which provides the example instructs you to modify the all-packages.nix file in a clone of the nixpkgs repository). ...Which is unhelpful with the mindset of "I just want to write a Nix package for my thing", or just weird compared to what you'd expect from "Hello World". (But makes more sense in terms of "how to get started with nixpkgs"). The UX is much better with Nix Flakes. -- With flakes, there's a standard file format where you can run "nix build" and expect it to work.

takeda 5y ago
The problem is that default.nix is like setup.py for Python. It allowed people do all kinds of nonstandard things and custom code. The callPackage pattern was developed later on, and people who use it as some kind of standard, but it was just one more "standard", also cli tools never were update to accommodate is, so that's why the complicated string is used. The flakes are essentially supposed to standardize it: https://www.tweag.io/blog/2020-05-25-flakes/ https://www.tweag.io/blog/2020-05-25-flakes/ (well their goal is to fix other issues, but the standard format of the file fixes that problem too and CLI supports it as well)

ParetoOptimal 5y ago

What resources led you to try: default.nix (i'm guessing): derivation { name = "simple"; builder = "${bash}/bin/bash"; args = [ ./simple_builder.sh ]; inherit gcc coreutils; src = ./simple.c; system = builtins.currentSystem; } Command: nix-build -E 'with import <nixpkgs> {}; callPackage ./default.nix {}' Rather than something like this[0]: default.nix: with (import <nixpkgs> {}); derivation { name = "simple"; builder = "${bash}/bin/bash"; args = [ ./simple_builder.sh ]; inherit gcc coreutils; src = ./simple.c; system = builtins.currentSystem; } Which can be built with: nix build We should fix the docs that led your version rather than the second. 0: https://nixos.org/guides/nix-pills/working-derivation.html#idm140737320270416 https://nixos.org/guides/nix-pills/working-derivation.html#i...

scintill76 5y ago
I’m an intermediate Nix user - aren’t pkgs usually passed in as an argument so that the caller can choose them? I sort of accepted that verbose command line as a necessary evil of good design.

takeda 5y ago

> - Examples that just don't work. yes, the nixpkgs changes and some old articles might no longer be accurate :/ > - Commands that run and no output is given, even though the text I'm following says it should output information I need. could you give an example? > - Do I need nix-darwin? Well, the readme explains what it is: "Nix modules for darwin, /etc/nixos/configuration.nix for macOS." What? (Finally I found an answer at Stack overflow, and it seems I don't need it. Seems to be kind of NixOS on top of macOS) yes, you don't need it for what you described. nix-darwin is basically to provide configuration functionality of NixOS to your Mac. Nix-darwin is 3rd party product that's written in Nix for Nix. Similarly Home Manager. > - 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? a lot of people wrote about it. This is a convention that evolved from nixpkgs, it's still not officially supported by CLI tool (that's why the command looks so complicated, it's similar to calling `python -c "<whatever>`), seems like the default.nix file which is very similar in concept to setup.py (as you can put whatever you want inside) is being replaced by more stricter flakes.nix file. Which in a way brings some similarities to the callPackage convention. > - An issue open since 2018 that the manuals simple example doesn't build: https://github.com/NixOS/nix/issues/2259 https://github.com/NixOS/nix/issues/2259 People chiming in years later that they only could build the example after reading the suggestions in that issue. Because software evolves and old versions of file like to disappear with time. I run into this as well, although it was nix pills documentation. My solution was to simply get the new version of hello and use that. Although I agree, that's still unnecessarily confusing. I think a proper solution would be to host the file on the own server. Or even better, make a basic hello.c file and list its content in the doc. > - And now I can't start my nix-shell because it says there's a problem with SSL certificates. I'm giving up. You most likely uninstalled nss-cacert package. Perhaps `nix-env --rollback` would help.