https://hackmd.io/axI1tQdwQB2pTJKt5XdY5w#Next-gen-conda-recipe-spec
It would be great if there was a better story for optional dependencies.
The special-casing of test requirements is inconsistent with the requirements for host/build/run.
The fact that you can't independently install the test dependencies is a huge usability wart and suggests there should be a better way of supporting them.
I think that rather than special-casing test dependencies, that test should simply be another sub-category under requirements alongside host/build/run.
Taking this idea further, a user could define any sub-category they wanted under requirements - e.g. dev, docs, etc...
In the case of dask they would define sub-categories array, bag, dataframe, distributed, diagnostics, delayed:
https://github.com/dask/dask/blob/master/setup.py#L10-L28
As it is, conda forces you to take an all or nothing approach - e.g. https://github.com/conda-forge/dask-feedstock/blob/master/recipe/meta.yaml
Even if all you want to use is dask.array you're forced to install the dependencies for everything.
The answer often given is to use outputs, and that's what we do ourselves - every package builds pkg-test, pkg-docs and pkg-dev metapackages along with pkg itself.
Whilst this can be made to work, IMHO it's a poor substitute for proper support for optional dependencies.
Ideally a recipe maintainer could specify whatever sub-category under requriements they wanted and conda would allow you to install that sub-category independently.
e.g. using pip syntax it would be
conda install dask[array,bag]
It has been argued that the pip syntax conflicts with existing conda syntax which is a fair argument, but there could be other ways to specify optional dependencies - e.g.
conda install dask --include-deps array --include-deps bag
conda install dask could then be used as an alias for conda install dask --include-deps run
This proposal requires a change to the yaml spec and also support from conda/mamba.
The yaml changes could be made backwards compatible by allowing test requirements to be specified either under test/requirements or requriements/test with a suitable deprecation period.