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
The most important feature of the groups module was the overriding which is a separate module now. Therefore removing the fact that groups are used from the docs to decrease the API surface to maintain.
Instead render the override and overrideAll options in the manual of pdm correctly by setting `overrideType`.
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.
* add derived graph
* rework graph sanitizing based on list keys
* figure out details for builder
* format stuff!
* try get groups working
* nodejs: fixups for new v3 builder
Co-authored-by: Johannes Kirschbauer <hsjobeki@gmail.com>
---------
Co-authored-by: DavHau <hsngrmpf+github@gmail.com>
add option: 'trustedDeps'. Only install scripts of explizit added dependencies are run.
In the future there may be wildcards to allow running all install scripts
