conda-forge / libitk-feedstock

A conda-smithy repository for itk.
BSD 3-Clause "New" or "Revised" License
4 stars 13 forks source link

how to avoid version conflicts in feedstocks that depend on libitk? #75

Closed KrisThielemans closed 3 months ago

KrisThielemans commented 2 years ago

Comment:

Our STIR feedstock uses libitk in our recipe as follows:

requirements:
  build:
    - {{ compiler('c') }}
    - {{ compiler('cxx') }}
    - cmake
    - ninja
  host:
    - libitk-devel
    - libitk <5.2  # [win]
    - libitk  # [not win]
  run:
    - {{ pin_compatible('libitk', min_pin='x.x', max_pin='x.x') }}

(cutting out non-ITK stuff). The pin_compatible line was put in by @carterbox in an attempt to fix the problem that the tests or actual downloaded package uses a different version of ITK than what was used to build, resulting in shared-libraries not found, but it is still happening, see https://github.com/conda-forge/stir-feedstock/issues/34

Any suggestions how we should fix this properly?

hmaarrfk commented 3 months ago

Ultimately, our strategy at conda-forge is to make bleeding edge easy to stay on.

Today, it seems like you are doing it correctly by relying on the run_exports. https://github.com/conda-forge/stir-feedstock/blob/main/recipe/meta.yaml

I'm trying to:

  1. Only require the libitk_devel package for the run_export to get picked up: https://github.com/conda-forge/libitk-feedstock/pull/93
  2. Add a global pinning at conda forge to help with this migration: https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/6243
hmaarrfk commented 3 months ago

I am closing since the issue was made in 2022 and I think we can get to resolution quickly.