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

Track packages that are released in ROS build farm but are/should be in conda-forge #17

Open
traversaro opened this issue Dec 20, 2020 · 9 comments

Comments

@traversaro
Copy link
Member

traversaro commented Dec 20, 2020

The ROS Debian binary packages that are released via Bloom are essentially a distribution of software that builds on top of another distribution of software (the base Debian/Ubuntu repositories). This relation is similar to the one that in the conda world exists between conda-forge and bioconda channels, and in a sense is the same relation that we would like to create between conda-forge and robostack.

Over the time some packages that we not ROS-specific (i.e. they did not depend on the ROS communication middleware) were released with Bloom for several reasons. The major reason is that it was much faster and easier to get a package published via Bloom rather then by going through the actual Debian/Ubuntu packaging process, while in some other cases a package was indeed available in Debian/Ubuntu repos, but the version available in the repos was not recent enough, and it was not possible to update it due to Debian policies for updates in already released distros.

In the case of robostack, given that getting new packages in conda-forge is relatively easy and fast, and the same holds for updating the version of existing packages, I think it make sense to avoid to re-build packages that are or should be in conda-forge even if they are release in bloom/rosdistro, but rather we should have some systematic way to skip them and install the conda-forge version instead. I am not sure what is the proper way of doing so, but for the time being I opened this issue to track the occurrences of this pattern that I spot.

Package repo It is already in conda-forge? rosdistro package name Does the rosdistro package also adds some files? Related issue(s)
https://github.com/pybind/pybind11 https://github.com/conda-forge/pybind11-feedstock pybind11_catkin in ROS1, pybind11_vendor in ROS2 Yes RoboStack/ros-noetic#19
https://github.com/OctoMap/octomap https://github.com/conda-forge/octomap-feedstock octomap No ros/rosdistro#26527
https://github.com/flexible-collision-library/fcl https://github.com/conda-forge/fcl-feedstock fcl No ros/rosdistro#27789
https://github.com/IntelRealSense/librealsense No librealsense No robotology/robotology-superbuild#564
https://github.com/borglab/gtsam Yes gtsam No ros/rosdistro#23198
https://github.com/ethz-adrl/ifopt No ifopt No
https://github.com/stack-of-tasks/pinocchio https://github.com/conda-forge/pinocchio-feedstock pinocchio No
https://github.com/oxfordcontrol/osqp Soon, conda-forge/staged-recipes#13587 osqp_vendor Yes, the CMake config files for the osqp_vendor CMake package, and the osqp_vendor-extras.cmake file. See https://github.com/tier4/osqp_vendor
https://github.com/OGRECave/ogre https://github.com/conda-forge/ogre-feedstock rviz_ogre_vendor Yes, it also installs the CMake config files for the rviz_ogre_vendor CMake files, and some additional related files. Furthermore, just on Windows the used ogre also statically links a locally built copy of freetype and zlib.
https://github.com/stack-of-tasks/eigenpy Yes eigenpy No.
https://tvm.apache.org/ https://github.com/conda-forge/libtvm-feedstock tvm_vendor Yes, it even enables some options while compiling tvm, that are related to vulkan and spirv, that I am not sure if they are available in conda-forge.

Just for ROS2, there are a few more in https://github.com/ros2/?q=vendor .

@traversaro
Copy link
Member Author

@traversaro traversaro changed the title Track packages that are released in rosdistro but are/should be in conda-forge Track packages that are released in ROS build farm but are/should be in conda-forge Dec 29, 2020
@traversaro
Copy link
Member Author

An interesting case of this packages are the one that do not depend on anything ROS-specific and so can go in conda-forge, but that use the ROS-like strategy of a single repo with multiple directories that contain different interdependent CMake or Python packages (see for example https://github.com/ethz-adrl/ifopt or tesseract, https://github.com/ros-industrial-consortium/tesseract tesseract-robotics/tesseract#419).

An example of this kind that is already in conda-forge is orocos-kdl (see https://github.com/conda-forge/orocos-kdl-feedstock/blob/master/recipe/meta.yaml) that indeed is using a multi-output recipe structure for which each "package" results in a different output. I don't know if vinca can help in this case, even if the recipe then goes in a usual conda-forge feedstock.

@traversaro
Copy link
Member Author

I added eigenpy to the table @wolfv .

@Tobias-Fischer
Copy link
Contributor

There's also fcl_catkin which is used by exotica, and should pull in conda-forge's fcl instead of building it.

/cc @wxmerkt

@wxmerkt
Copy link

wxmerkt commented Apr 7, 2021

Regarding fcl_catkin, once upstream makes a new FCL release (flexible-collision-library/fcl#532) and updates it as ros-noetic-fcl, I am considering unreleasing fcl_catkin from Noetic altogether (ipab-slmc/exotica#735 makes its use redundant). The primary motivation for it was to provide bleeding edge FCL when there was no ros-*-fcl and now that there is, it has outlived its purpose.

@Tobias-Fischer
Copy link
Contributor

In ROS2, we now also have tvm-vendor which should be unvendored.

@traversaro
Copy link
Member Author

traversaro commented Jul 3, 2022

apriltag (https://github.com/AprilRobotics/apriltag, https://repology.org/project/apriltag/versions) is another package that is released as part of ROS but could also be a standalone package in conda-forge, see discussion in stack-of-tasks/pinocchio#1700 .

@traversaro
Copy link
Member Author

A strange package of this kind is urdf_parser_py/urdfdom-py. A rather old version is availably on PyPI: https://pypi.org/project/urdf-parser-py/ , however new versions are regularly released in ROS: under the urdfdom_py name: https://index.ros.org/r/urdfdom_py/ . The fact that is not on conda-forge is blocking the release of downstream packages that depend on it: ami-iit/adam#26 .

@traversaro
Copy link
Member Author

xref: BehaviorTree/BehaviorTree.CPP#644

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

No branches or pull requests

3 participants