Add extras to conda-forge feedstocks

[tcompa]

I just realized that conda packages do not have extras. This means that especially the fractal-tasks-core conda-forge package cannot install task dependencies (e.g. cellpose).

See for instance this issue and links therein. One relevant quote:

So e.g. we end up with some package "pack" on pip, with "pack[recommended]" installing the most typical dependencies, "pack[all]" installing lots of extra things, and "pack" installing only the bare minimum. On conda we maybe get "pack" installing the most typical dependencies, sometimes "pack-core" (a dependency of "pack") installing the bare minimum, and "pack-extras" installing the extra stuff.

There are multiple options to be explored, e.g. the use of outputs, or also

• [recipe-spec] Allow for arbitrary optional dependencies mamba-org/boa#245
• ENH: More powerful syntax for build variants & optional package-extras conda/conda#11053
• https://github.com/conda-forge/airflow-feedstock/blob/main/recipe/meta.yaml#L185
• Optional groups of dependencies conda/conda#7502
• Mirroring the pip sub-package (extras) dependency semantics conda/conda#2984

[imagejan]

Yes, the conda way of doing this would be to create separate conda packages for each useful combination of extras, or just ship the packages without extras and leave it up to the consumer to install any additional (optional) dependencies into their environment.

I think it would be useful to have fractal-tasks-core as a bare package with no optional dependencies on conda-forge.
It's fine to add the extra dependencies "manually" to any production environment.

Alternatively, you can also make a fractal-tasks package that depends on fractal-tasks-core and all dependencies of the fractal-tasks extra, without adding any additional functionality?

Update: the correct term for the suggested fractal-tasks package would be "meta package", I think.

[tcompa]

Thanks for this feedback!

I think it would be useful to have fractal-tasks-core as a bare package with no optional dependencies on conda-forge.

Good to hear, especially since this is some low-effort kind of maintenance.
I've made a few intermediate releases, and I triggered the 1.3.3 conda-forge release (conda-forge/fractal-tasks-core-feedstock#19). Both for this and upcoming PRs: if they do not require too much effort, I can keep merging them so that new releases are published regularly (without the optional dependencies though).

[imagejan]

Thanks @tcompa, this is helpful.

For what it's worth, I've had good experience using the conda-forge automation to automatically merge pull requests that update the version (@conda-forge-admin,please add bot automerge, see e.g. conda-forge/faim-ipa-feedstock#8) and to render version updates immediately after releasing on PyPI (@conda-forge-admin, please update version, see e.g. conda-forge/faim-ipa-feedstock#10).

Maybe this helps lowering the maintenance burden for the conda releases.

I'd suggest creating a metapackage still makes sense as well for the (relatively complex) fractal-tasks extra, but no urgent need from my side 🙂