Ipk: issue related to boost-cpp version which differs in bioconda-build CI and local install. #49000
Conversation
* Squash and merge
This reverts commit 859c9a1.
…t are not present by default
… issues in CI docker.
…nstalling the package
blinard-BIOINFO
changed the title
|
It works on my side on macOS, boost-cpp 1.85 is used. and your channel priority? |
|
It uses 1.85 for me too! |
|
The issue comes from the fact that my default conda installation uses flexible priority. As mentionned here: https://github.com/conda-forge/boost-feedstock I was wondering if there is any way to set a directive in the meta.yaml so that channels priority is set as strict for a particular package (e.g boost-cpp in our case) ? |
|
Also, in a fresh environment, where I install only package If you do no observe this behavior, I suppose this could be related to boost-cpp version issue. |
|
Last element.
Temporary solution is to manually fix both to |
|
Usually we prefer to keep compatibility as large as possible, so preferring I do not see any problem at short term to set boost-cpp to 1.85 (both for EPIK and IPK recipes) but if What is your thought @martin-g ? |
Indeed, because it is serialized via boost library. Boost guarantees correct de-serialization only for the same version of the library. Problem is, there is no good mechanism at de-serialization time to verify which library version was used at serialization time... We scratch our heads about this for some time now and the best solution we found was to ensure same boost headers version in the compile environment (I basically do the same in conda). Initially, the choice of package separation is because IPK creates databases that can be used by different tools. For instance, the package I agree with you, ultimately the solution could be to merge all tools into one conda recipe. But then, to make the release mechanism work, we will have to create a "merged" github repo, with its own releases, for a single conda package. In the meantime, I would be happy to stick to |
|
According to https://www.boost.org/doc/libs/1_85_0/libs/serialization/doc/todo.html#backversioning it should be possible to read data serialized with an older version. I also don't like pins to exact version but in this case it sounds like the best idea. |
Pin boost to 1.85 as discussed at bioconda#49000 Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
Pin boost to 1.85 as discussed at bioconda#49000 Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
* epik: add linux-aarch64 build Pin boost to 1.85 as discussed at #49000 Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org> * Use `long double` as a replacement for float128 on aarch64/arm64 Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org> * Add osx-arm64 --------- Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
Package does not work because of different behavior in conda-build CI and install on some local computer.
@martin-g @Juke34
I'm getting a weird behavior related to boost following the package development.
In the conda-build CI, package
boost-cpp=1.85got selected for the conda env.My rule initially required
boost-cpp>=1.67.As one can see in the CI logs of PR #47946 :
So the binary is built with boost v1.85 on bioconda side.
However, when installing on a fresh env in my local computer, conda or mamba refuses to use
boost-cpp1.85 and stick to boost-cpp 1.84. This results to a conflit of shared boost librairies and the program fails to run.I looked at the repo libboost-feedstock which maintains
boost-cppand it seems this can happen if channel_priority is not set to strict for conda-forge. I check the documentation, but so far did not found a way to force "strict" priority for a bioconda recipe. Is this even possible ?In this PR, I set the
boost-cppversion to a strict version in the recipe, hoping this will resolve the issue.But I wanted to let you know that this weird behavior happens (and may break potential other libboost-based packages, which may be super common for C++ packages).
The worse part is that all looks clean in your CI side, then you merge to make it available online, and then things get messed-up when someone is actually installing the package on his/her computer.