Re: Should a Guix package include documentation dependencies to be considered complete?

[Attila Lendvai <attila@lendvai.name>]

> 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)