Maintenance of the conda package
To build the iota2 conda package, we use two kinds of python packages:
- manually compiled: recipes are available in the install folder. (OTB and its dependencies, grass,...)
- Already compiled packages available on different channels: conda-forge, anaconda
In examples provided by conda and other users, the pinning of packages is avoided as often as possible.
The conda solver must find the optimal combination of packages version, and produce a fully operation package.
The solver tries to use the most recent versions, but in some cases we must use a previous version. For instance OSSIM which is an OTB dependence works only with old geos version.
Then sometimes the iota2 build fails without any modification on your side.
Recipes and packages
We must also pay attention to the packages added in the recipes. The command
conda search packages --info
conda search packages=version --info
displays the available versions and dependencies.
This makes it possible to identify, for example, a package added without justification: libboost
.
Indeed, boost
in conda-forge channel already has a library package in its dependencies: boost-cpp
.
libboost
is available in anaconda
channel and raise several conflict when compiling with boost-cpp
as they are the same.
Manage versions
It is possible to use two files to configure a conda-build run!
conda_build_config.yaml
- a jinja2 file, named
common.j2
used to define variables. Thanks to OTB recipes
I'm not sure I know the exact difference between these two files and how conda uses them. In any case if a version is indicated in the conda_build_config file, then any occurrence of this package will use the indicated version.
In the case of the jinja2 file, this file must be imported into each recipe and we must call to the corresponding variable.
The jinja2 file was chosen as it allow to fix constraint in one file and versions must be used explicitly.
Debugging a recipe
There are no tools to find and solve a conflict while installing the building environment. Most of existing tools are dedicated to debug the compilation step.
Identifying potential conflict:
- use
conda search
to check dependencies For instance some version oflibtiff
requireproj
and notproj4
. We useproj4
in all our recipes andproj
have an excluding constraint aboutproj4
. Then this create a unsolvable conflict.
Starting from scratch:
- try to install manually every package required in recipes
- mamba seems to provide a fast solver and more explicit message about conflicts
- pay attention to package already installed which require a upgrade or a downgrade
Starting from a working environment:
- fix all version and try to compile
- Then remove version one by one to identify which package are conflicting
Bypass the problem:
- Update the recipe to be boa friendly. Boa is based on conda build but use the mamba solver, then the error message could be more explicit. But it is always in development and the recipe format are not yet fixed. Also the boa recipes cannot be used with conda build directly. Then it add a maintenance step.