Georg Schramm

It seems that most of the optional dependencies (e.g. cups) are already in conda-forge, so there is hope that we could build a version with most of the opt. functionalities...

@MStraeten @kmilos @TurboGit as far as I can see you do not execute any unit tests in the [build.sh](https://github.com/darktable-org/darktable/blob/master/build.sh). Am I overlooking something?

@zisoft In principle conda-forge would allow to use one build system for all platforms (various Linux architecutues, MacOS Intel + Silicon, Windows) (also allow CUDA build if ever needed ...)....

Sounds great. Before creating the conda-forge "recipe" a few short questions: - Which pytorch version required? - Which of [those tests](https://github.com/facebookresearch/fastMRI/tree/main/tests) should be run when building the package?

> Sounds great. Before creating the conda-forge "recipe" a few short questions: > > * Which pytorch version required? > > * Which of [those tests](https://github.com/facebookresearch/fastMRI/tree/main/tests) should be run when...

@mmuckley I did a generate a first conda-forge fastmri recipe using grayskull based on the pypi package. Unfortunately, it seems that the run requirement `runstats` is not (yet) on conda-forge....

@mmuckley conda-forge build is on its way :) Why do you have different reqs for install and testing in `setup.cfg`? Right now some tests in `test_modules.py` fail with newer versions...

A few things that come to my mind are: - use of "selectors" (e.g. `cuda_comiler_version == `) - how to use `run_exports` - runtime requirement on `__cuda` - conventions for...

@KrisThielemans and I am using non-TOF mMR data from the examples ;)

But good to keep that in mind and maybe warn people. + another reason to use `torch.autograd.gradcheck` to verify custom layers ...