search

conda-forge / pinocchio-feedstock

A conda-smithy repository for pinocchio.
BSD 3-Clause "New" or "Revised" License
12 stars 10 forks source link

WIP: Probably a good strat to maintain pinocchio 2 and hpp 1 without unpinning recipes or freezing packages #81

Closed ymontmarin closed 1 year ago

ymontmarin commented 1 year ago

Checklist

conda-forge-linter commented 1 year ago

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

conda-forge-linter commented 1 year ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

ymontmarin commented 1 year ago

@conda-forge-admin, please rerender

jcarpent commented 1 year ago

@ymontmarin Could you explain a bit what are the rational?

jcarpent commented 1 year ago

I would suggest discussing first, and try to keep this feedstock as simple as possible.

ymontmarin commented 1 year ago

Modification There are only two little modifications:

To reverse, we only need to delete the 3 lines in recipe/conda_build_config.yaml and rewrite only hpp-fcl in place of the two lines branching in recipe/meta.yaml and rerender.

Those changes DOES NOT affect the actual behavior of the recipe and its builds. It only adds extra builds with hpp-fcl 1.8.1.

Why do we need this ? The hpp-xxx stack (14 packages) is actually broken, mainly because it requires the pinning pinocchio >=2.0 < 3 and hpp-fcl >=1.0 < 2. But all the concerned package are C++ package that use the mention:

run_export:
    pin_subpackage({{ name }}, [...])

which tell conda that when doing build, the run requirements pinning must be the same as the version used for the build. Which let us with 3 main approaches to make the hpp-xxx stack work again:

  1. remove the run_export pinning in hpp-fcl to allow for installing pinocchio latest and hpp-fcl 1.8.1 together. We still need to maintain hpp-fcl 1.8.1 builds (which is not a problem), BUT I really think unpinning hpp-fcl is a bad idea, espacially between two different major versions.
  2. Froze the hpp-xxx stack to a version a date where we had hpp 1.8.1 and pinocchio 2.x.x, but such version combinaison build is not rebuild, so it depends on all the version at the time of the packages that used run_export pinning ! So in order to make this freeze work, we need to exactly pin exactly a lot of packages (boost, assimp, ffmped, urdfdom...) across all 14 hpp packages. In addition of being a labyrinthine system, it will fixe hpp-stack for automatic upstream update BUT it willl not allow for reg-bot migration deployments ! And it will use version of packages that are not the one of conda-forge/pinning-feedstock.
  3. Maintain an hpp-fcl v1 branch with hpp-fcl 1.8.1 that allow for migration deployments AND make pinocchio build against the two branches (which is what this PR is about)

While 1. only affect 1 package it unpins a C++ package. 2. is not con-forge friendly as it writes hard versioning everywhere and freeze migration deployments. I really think 3. is the simplest and the safest option even if it touch 2 packages. It is straightforward: keep maintaining 1.8.1 and latest version of hpp-fcl (already done in this PR, and build downstream package with the two versions hence this PR for pinocchio.

We could also wait for Pinocchio 3, and let hpp stack done, but it block migration that can be forgotten when we will restart the stack; and it maintain hpp-stack at v4.10 instead of v4.13. In addition the work to do for hpp-stack will be hudge when Pinocchio 3 will be available. With this solution, we can have the hpp-stack work and the only work to do when pinocchio 3 is available will be: remove a branch, unpin hpp-package to 1.8.1, remove hpp-fcl branching on pinocchio feedstock.

I am willing to discuss this for any suggestions.

ymontmarin commented 1 year ago

@conda-forge-admin, please rerender

ymontmarin commented 1 year ago

Actual difference without the rerender noise: image

ymontmarin commented 1 year ago

Hi @traversaro !

Following your suggestion in this PR https://github.com/conda-forge/hpp-pinocchio-feedstock/pull/13 in the work on making hpp-xxx packages work again and allowing to finish the migrations, I continue to avoide freezing the packages dependencies to old version of boost, assimp...

To be able to have hpp-fcl >= 1.0 <2 while pinocchio >= 2.0 <3 and builds compatible with recent versions of boost, assimp... I created as you suggested v1 branch that is reference as abi_migration on hpp-fcl-feedstock https://github.com/conda-forge/hpp-fcl-feedstock/tree/v1 and it works well !

Now to use it for hpp-pinocchio, I have the following constraint: hpp-pinocchio links with hpp-fcl AND pinocchio, while pinocchio also links directly with hpp-fcl. Due to the run_export(compatible) of hpp-fcl, I need a pinocchio build that was build with hpp-fcl 1.8.1. But in the current state, in pinocchio recipe, it builds with the latest hpp-fcl and builds with hpp-fcl 1.8.1 are olds and were build with old version of boost, assimp... To solve that, without unpinning hpp-fcl, I used what I learned in this and this create a build matrix for pinocchio recipe, to build with hpp-fcl latest AND hpp-fcl 1.8.1. This is this PR.

I think it will allow us to finish to fix hpp-xxx stack.

Could you validate the approach ? Thank you very much for your help !

traversaro commented 1 year ago

Hi @ymontmarin, yes that is a valid approach. We used it in the ignition/gazebo libraries to build for both ogre 1.10 and 1.12:

ymontmarin commented 1 year ago

Thank you @traversaro !

jcarpent commented 1 year ago

Thanks @ymontmarin and @traversaro for your efforts.