Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support generating conda binaries for ROBOTOLOGY_USES_PYTHON option #641

Closed
traversaro opened this issue Feb 28, 2021 · 5 comments · Fixed by #749
Closed

Support generating conda binaries for ROBOTOLOGY_USES_PYTHON option #641

traversaro opened this issue Feb 28, 2021 · 5 comments · Fixed by #749

Comments

@traversaro
Copy link
Member

traversaro commented Feb 28, 2021

In the conda-forge based CI and in https://github.com/robotology/robotology-superbuild/blob/master/doc/conda-forge.md, the option ROBOTOLOGY_USES_PYTHON has not been tested until now, and this may be quickly bites us as while conda is now a language-agnostic package manager, it has its roots and it is mainly used as of 2021 by the Python community.

Support for the building from source workflow

This is tracked in #615, so this issue is now just about generating binaries for ROBOTOLOGY_USES_PYTHON .

@traversaro
Copy link
Member Author

traversaro commented Feb 28, 2021

Support for generating conda binaries

For the generation of conda binary packages that is currently tracked in #620, some additional tweaks are necessary. In particular, while on macOS or Linux the usual installation process will work fine, on Windows the layout of the installed packages are a bit different. In particular on Windows given a <conda_env_prefix>, the MSVC-compatible C++ libraries are all installed in <conda_env_prefix>\Library\include, <conda_env_prefix>\Library\lib and <conda_env_prefix>\Library\bin, and this is typically obtained by setting CMAKE_INSTALL_PREFIX to <conda_env_prefix>\Library on Windows. However, the Python packages instead would need to be installed in <conda_env_prefix>\Lib\site-packages, so they should be installed outside of CMAKE_INSTALL_PREFIX . To do so, we need to instruct each superbuild package that installs Python extension of code to install it <conda_env_prefix>\Lib\site-packages.

The CMake options that can be used in this context are:

A quick check shows that the appropriate CMake options on Windows are:

To insert them, we need also a mechanism to inject this CMake options only when a conda recipe is generated, and not when the the projects are compiled via the robotology-superbuild .

@traversaro
Copy link
Member Author

As @singhbal-baljinder is experimenting with Python-based learning library and for several of them the installation via conda is the easiest option, it is a good idea to fix this.

@traversaro
Copy link
Member Author

❌ iDynTree: no option is present, it should be added, see robotology/idyntree#834

Will be fixed by robotology/idyntree#852 .

@traversaro traversaro changed the title Support ROBOTOLOGY_USES_PYTHON on conda-forge Support generating binaries for ROBOTOLOGY_USES_PYTHON option Apr 11, 2021
@traversaro
Copy link
Member Author

Another aspect to handle is that, differently from most other C++ dependencies, Python is supported in several versions in conda-forge (at this time, if I am not wrong 3.6-3.9) so we would need to add some kind of variant (https://docs.conda.io/projects/conda-build/en/latest/resources/variants.html) support in our generate recipes. Probably a possible strategy to try is just to rely on the existing conda-forge pinning file (see https://github.com/conda-forge/conda-forge-pinning-feedstock) that can be just installed as conda install -c conda-forge conda-forge-pinning and then passed as additional conda_build_config file in https://github.com/robotology/robotology-superbuild/blob/master/.github/workflows/generate-conda-packages.yaml#L107 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant