Comment by hinkley

Comment by hinkley 10 months ago

If you design it like SCons, it'll look imperative but behave more declaratively.

If I understand the architecture correctly, the imperative calls in the config file don't actually run the build process. They run a Builder Pattern that sets up the state machine necessary for the builds to happen. So it's a bit like LINQ in C# (but older).

I have no idea how that plays out single-step debugging build problems though. That depends on how it's implemented and a lot of abstractions (especially frameworks) seem to forget that breakpoints are things other people want to use as well.

zombiezen 10 months ago

That's accurate (unless the config file attempts to read something from the build process, that will trigger a build).

It's a good point about debugging build problems. This is an issue I've experienced in Nix and Bazel as well. I'm not convinced that I have a great solution yet, but at least for my own debugging while using the system, I've included a `zb derivation env` command which spits out a .env file that matches the environment the builder runs under. I'd like to extend that to pop open a shell.

Reply View 30 replies

pdimitar 10 months ago

Surface-level feedback: get rid of the word "derivation". Surely there must be a better way to describe the underlying thing...

Reply View | 25 replies
- imiric 10 months ago
  
  Agreed! It's such an alien term to describe something quite mundane. Language clarity is a big part of a friendly UI.
  
  Reply View | 3 replies
  
  ulbu 10 months ago
  
  what word would you fit to what a nix derivation is?
  
  Reply View | 2 replies
- umanwizard 10 months ago
  
  What’s wrong with it? It’s a term of art that means a specific thing in both nix and guix; it’d just be confusing if zb renamed it to something else.
  
  Reply View | 9 replies
  
  kstenerud 10 months ago
  
  I'm 80% finished moving all of my servers from NixOS to Debian. I used NixOS for 3 years (even wrote some custom flakes) before finally giving up (for the final year I was just too scared to touch it, and then said "I shouldn't be scared of my OS"). I should know what "derivation" means, but I can't for the life of me remember...
  
  Reply View | 8 replies
- nurettin 10 months ago
  
  It is the name of a feature in Nix. This is as obfuscated as calling a rock a rock.
  
  Reply View | 10 replies
  
  pdimitar 10 months ago
  
  Strange thing to say but you do you.
  I tried to dabble in Nix several times and the term never stuck.
  I suppose for you it's impossible to accept that the term is just bad and unintuitive. And other comments here say the same.
  
  Reply View | 9 replies
skybrian 10 months ago

One thing I like to see is a 'dry run' like 'make -n'. Although, maybe that's not possible in all cases.
Another possibility might be to output a something like a shell script that would do a rebuild the same way, so you can see what it did and hack it when debugging.

Reply View | 3 replies
- photonthug 10 months ago
  
  Yes. Dry runs at least, and better yet terraform-style planning that produces an artifact that can be applied. These should really be more common with all kinds of software
  
  Reply View | 2 replies
  
  hinkley 10 months ago
  
  I would like to see more tools iterate on trying to do terraform-like output because while terraform diffs are interesting, practically most of my teammates couldn’t tell what the fuck they said and a couple times I missed important lines that caused us prod issues. I think we can do a better job than showing a wall of text.
  
  Reply View | 1 reply
  
  photonthug 10 months ago
  
  Presentation is a separate matter though, just like with git diffs ideally you could choose a wall of text or a side by side ui, see things at a high level or drill down to line by line. A tag layer plus custom validation between plan/apply gives you an automatic way to short circuit things. But none of it can work without a plan as a first class object.
  Thing is the plan/apply split isn’t even primarily for users necessarily, it’s just good design. It makes testing easier, and leaves open the possibility for plugging in totally different resolution strategies without rewriting the whole core. The benefits are so big there that I’d strongly prefer that more software is using it more often, even if I’m going to shut my eyes and auto apply every time without glancing at the plan.
  
  Reply View | 0 replies