conda-forge

[KrisThielemans]

Now that we're on PyPI, we want to be on conda-forge as well. Ideally, we want both Python and C++, possibly in different packages?

• Currently, the generated C++ is just the source (no need to compile), so this could be "easy".
• I guess Python-only could just use the PyPI package.

I'm not sure what the best strategy is here. @casperdcl @gschramm @johnstairs @naegelejd suggestions?

[casperdcl]

See #37 for discussion

[gschramm]

If we have the C++ / python sources available in a tagged gh version, creating the recipe "should be easy".

We should decide whether we want to have one package including C++ and python, or to have 2 packages.
The latter has the advantage that we can auto-create a conda-forge recipe getting the sources from pypi.

[naegelejd]

I can share what we do for MRDv2 artifacts (and ISMRMRD long before MRDv2). C++ and Python are handled separately.

C++

1. After generating the model code, we build a C++ shared library (e.g. libmrd.so) and link that with the MRD C++ tools. This is also where we handle the "include_directories" issue and include any additional helper code. The shared library is linked with the MRD command-line tools. This also generates CMake config files for downstream CMake users to easily find_package(mrd).
2. In the GitHub CI pipeline, we build and publish a conda package for each OS that contains the headers, shared library, and command-line tools.
3. We also create a tarball of just the C++ source code (excluding Python, MATLAB, etc.) and upload that to GitHub releases for easy use with CMake's FetchContent feature.

I would not publish the C++ source files. If a user wants the source code, he/she can just git clone it, and possibly re-run yardl generate, or use CMake's FetchContent.

Python:

1. A setup.py and pyproject.toml configuration is used with pip to build and publish a PyPI package, called mrd-python.
2. The same configuration is used with pip and conda-build to build and publish a Conda package, also called mrd-python.

All artifacts are linked on the GitHub Releases page. Example here.

[gschramm]

auto generation of the conda-forge recipe for petsird python package now works :)

If we agree to have separate python and C++ packages on conda-forge, I can stage the python recipe below and list
@KrisThielemans @casperdcl , me, ... as maintainers.

{% set name = "petsird-python" %}
{% set version = "0.2.1" %}

package:
  name: {{ name|lower }}
  version: {{ version }}

source:
  url: https://pypi.org/packages/source/{{ name[0] }}/{{ name }}/petsird-{{ version }}.tar.gz
  sha256: a5d346b1e0a594fa1ab3c5a630e7f24e3fc33a60bcce801aeb06f5648c997b68

build:
  noarch: python
  script: {{ PYTHON }} -m pip install . -vv --no-deps --no-build-isolation
  number: 0

requirements:
  host:
    - python >=3.9
    - setuptools >=42
    - setuptools-scm >=3.4
    - pip
  run:
    - python >=3.9
    - numpy >=1.22

test:
  imports:
    - petsird
  commands:
    - pip check
  requires:
    - pip

about:
  summary: Library and tools for working with PET Emission Tomography Standardization Initiative Raw Data (PETSIRD) data
  license: Apache-2.0
  license_file: LICENSE

extra:
  recipe-maintainers:
    - AddYourGitHubIdHere

[KrisThielemans]

sure, let's go ahead. We can do libpetsird later. Thanks!

[gschramm]

@casperdcl @KrisThielemans could add a comment in conda-forge/staged-recipes#28165 saying that you both are ok to be maintainers for the conda-forge recipe?

[KrisThielemans]

The python part of petsird is now also available from conda-forge https://github.com/conda-forge/petsird-feedstock. Thanks @gschramm !

[KrisThielemans]

I opened a new issue for C++.