adding libparallelproj to conda-forge-pinning-feedstock

[gschramm]

Comment:

libparallelproj which is part of the conda-forge package parallelproj contains C/CUDA libs consumed / linked by other projects - e.g. STIR (also on conda-forge).

Recently, the maintainer of STIR and the STIR conda-forge feedstock reported this issue occurring at the loading stage of libparallelproj caused by different versions used for building and when installing.

Because of that, I assume libparallelproj is a candidate to be added to conda-forge-pinning?
Or should the pinning be done manually in the STIR recipe?
Or do I need to define a run_export in the parallelproj recipe?

I am using semantic versioning for libparallelproj, so in principle STIR built with libparallelproj v1.7.1 should run with v1.7.3 - so I am also a bit lost on why there is a problem in the loading stage

[xhochy]

You should be:

1. Define a run_exports in libparallelproj
2. Add a migration to this repository and add the same version to the conda_build_config.yaml
3. Add a repodata patch for the old STIR builds so that they depend on the correct libparallelproj.

[gschramm]

@xhochy : thanks a lot for the feedback!

I am struggling to understand how the run_exports work / what they mean (after reading the.
Right now, we already have run_exports in the recipe of libparallelproj - see here, but I guess
they are not correct.

What we need is that respects semantic versioning meaning that an application build with libparallelproj vX.Y should run with all libparallelproj X.>=Y versions (and choosing the correct cpu vs cuda build)

[xhochy]

What we need is that respects semantic versioning meaning that an application build with libparallelproj vX.Y should run with all libparallelproj X.>=Y versions (and choosing the correct cpu vs cuda build)

Yes, this means you are missing a max_pin='x.x' in the pin_subpackage call.

[gschramm]

Could you also explain what:
"Add a migration to this repository and add the same version to the conda_build_config.yaml"
means and does?

[xhochy]

For a migration, you can see the following PR as an example: https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/5824/files It will take care that all repositories that depend on a package are rebuilt in topological order with the package pinned to the same versions.

[gschramm]

Many thanks again! So if I understand correctly, I will submit a PR containing

__migrator:
  build_number: 1
  commit_message: Rebuild for libparallelproj 1.8.0
  kind: version
  migration_number: 1
migrator_ts: "time stamp"
libparallelproj:
- 1.8.0

and the time stamp is the time stamp of the submission?

[xhochy]

Yes, in the example migration file there is a bit more documentation.

[gschramm]

ok. thanks. last question, since libparallelproj is build from the parallelproj feedstock, I guess it should be:

__migrator:
  build_number: 1
  commit_message: Rebuild for parallelproj 1.8.0
  kind: version
  migration_number: 1
migrator_ts: "time stamp"
lparallelproj:
- 1.8.0

libparallelproj replaced by parallelproj

[xhochy]

No, this needs to be the package that should be pinned, not the feedstock.

[gschramm]

Ah ok. Good that I double checked.
I think the comment in the example migration file here is a bit misleading