mkDerivation should be minimal, but currently it always pulls in modules like `lock` and `paths` etc. despite those not being needed for many instances, like when mkDerivation is imported by a dependency.
Modules like pip which do need some of these core modules, now need to directly depend on them.
This will remove a bunch of unneeded options which currently pollute the manual.
The remaining core dependencies of mkDerivation are now: deps, env, ui
Add options `overrides.${name}` and `overrideAll` to all language modules that manage a dependency tree.
This is done in a backward compatible fashion. Old options for overriding dependencies continue working, though those are not displayed in the manual anymore.
For the following modules the manual now suggest using the new unified override options:
- for pip: use `pip.overrides` and `pip.overrideAll` instead of `pip.drvs`
- for nodejs-granular-v3: use `nodejs-granular-v3.overrides` and `nodejs-granular-v3.overrideAll` instead of `nodejs-granular-v3.deps`
- `php-granular`: use `php-granular.override` and `php-granular.overrideAll` instead of `php-granular.deps`
Move some barely used modules to the experimental section to reduce surface.
Instead of the separate dev-shell module the nodejs package should have a devShell subattribute.
previously the options of other imported modules were not shown which gave an incomplete picture. For example the docs page for the `pip` module did not show the options prefixed with `mkDerivation` which are accepted and needed by the pip module.
It's better to have everything on one page for each module.
- don't import eval-cache and flags modules by default (those have never been used so far)
- mark options of package-func as internal. Those are for maintainers only and don't need to be rendered by default
- name example more consistently, eg. `{language}-packaging-{feature}` or `{language}-local-development-{feature}`
- move some examples to the modules integration tests directory instead as their purpose was mainly testing and they weren't good example
- module owned checks: import via flake if available
I always forget how to get going with dream2nix, and while this
page doesn't contain much more than you'd already find in the
examples, I do think it's a good starting point for allowing
people to start more confidently.
So far, /examples was the only place with packages that are built in the CI pipeline.
This change allows us to add package build tests to individual modules at the location where the module is defined. This has several benefits:
- We are not forced to add unnecessary examples in order to maintain test coverage
- When modules get removed, their tests will be removed alongside
- It allows us to keep old modules around and assure they keep working without having to keep outdated examples in /examples
The goal is to reduce the flake inputs visible to the user
Still, the top-level flake re-exposes the outputs of the dev-flake, but
without exposing its inputs. This means a devShell is still available in
the top-level, for example.
This also removes the /modules/flake.nix. Its original purpose was
separating the modules inputs from the development inputs, but this is
now done the opposite way around by moving the dev inputs to
/dev-flake/flake.nix.
