> We currently include all the dependencies to run the tests, why not do > the same for documentation building? > > Should we make it a requirement or goal to always package a given package's > "documentation-inputs"?
i also lack guidance on this. and i somewhat miss a "test-inputs" field to explicitly mark the dependencies that are only needed to run the tests. this often doubles the native-inputs dependencies of python packages. then the infrastructure could be smartened up to not require those dependencies when the tests are disabled for a package. it could serve as a temporary bandaid to fix/upgrade a package while there are some issues with the dependencies needed to run the tests. i guess same applies to documentation. some brainstorm follows: but what should be the way to control this for documentation? package arguments, like #:tests? #f for tests? or some way to mark some of the outputs as optional, and a way to request the optional outputs? how would the latter apply to tests, that have no package output? is the anomaly justified? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “To every man is given the key to the gates of heaven; the same key opens the gates of hell. And so it is with science.” — Richard Feynman (1918–1988)