It seems like in some parts of nixpkgs hooks are intensively used to make builds modular.
Is this the purpose that hooks were originally invented for?
If hooks are our module system for builds, why is this framework implemented in shell script. Shouldn’t we use the nix language to define such framework instead?
Current problems I see:
- Find failing hook: How can I find out which hook is the source of a failing command? Some hooks are nice and print a “starting hook: …”, but not all of them do that.
- Discoverability: If a hook is nice enough to announce its execution, how can I find its definition in nixpkgs?
- The announced name is often different than the attribute name and different than the file name. There is no clear relation.
- Some hooks are general build-support hooks, some hooks come from language frameworks, etc. There is no clear place to start looking.
- Predictability: How can I make reliable assumptions on what hooks will be running during my build, or find out why a specific hook is activated on my build?
- Hooks can be registered by any shell script of any layer at any time of the build. That seems chaotic.
- Some hooks are enabled/disabled conditionally during build time depending on state of the build (environment variables for example)
- Some hooks are only ran if other hooks decide to run them
The model seems to be full of side effects, everything can affect everything else, and the dependency tree is unclear.
Isn’t that contradictory to the idioms of nix and in some way re-creating the madness that nix originally tries to solve?