Release binaries

[mpowelson]

A few options. @Levi-Armstrong Feel free to edit to add more

• ROS-I PPA
• Snap package

Ideally this would happen in CI as if it is manual we are never going to do it.

[johnwason]

Conda is also an option. It claims to be platform independent, and would be good for Python integration. I don't have any experience using it.

[johnwason]

Also deploying PyPi wheel packages. This will require statically liking in all libraries and dependencies in to the Python C++ module.

[Levi-Armstrong]

Conda is also an option. It claims to be platform independent, and would be good for Python integration. I don't have any experience using it.

Yea, I recently started looking at Conda-Forge but not sure where to start. Have you every release anything on conda?

[traversaro]

Conda is also an option. It claims to be platform independent, and would be good for Python integration. I don't have any experience using it.

Yea, I recently started looking at Conda-Forge but not sure where to start. Have you every release anything on conda?

Regarding conda-forge, I was looking into packaging some of the dependencies of tesseract (in particular opw_kinematics and ifopt), so I would be happy to give an hand in packaging also tesseract.

At a first glance all the external dependencies used in https://github.com/ros-industrial-consortium/tesseract_ext are already available in conda-forge and updated to the latest version, so w.r.t. to that you should not need anything special.

I guess the first step is to ensure that you have a set of released version for tesseract and all its dependencies, and then the following step is adding recipes in https://github.com/conda-forge/staged-recipes .

[Levi-Armstrong]

@traversaro That is great news. We are cleaning up a few things and I plan to have the feature/CommandLanguage brach merged into master this week. We will create a tag prior to merging in this branch for those needing access to the current master. We will then create new tag release for the master after the merge of feature/CommandLanguage. I will reach out very soon once everything is merged and tagged.

[johnwason]

It is probably worth creating vcpkg portfile as well. I have found it is the best way to statically link a program, which is useful when creating a plugin or a final product.

[johnwason]

The conda ROS packages don't support Windows. It will be necessary to check the dependencies for tesseract to make sure they have Windows build scripts.

[traversaro]

The conda ROS packages don't support Windows.

To which package are you referring? The one in conda-forge such as are actually kind of deprecated (not sure how we could make clear this to users @wolfv @Tobias-Fischer) as it turns out that maintaining a large collection of software with no ABI compatibility policy on a distro such as conda-forge that heavily relies on ABI policies for ensure smooth transitions from one version to another (see https://conda-forge.org/blog/posts/2019-12-06-cfep09/).

The only current effort I am aware of for packaging ROS on conda is https://github.com/RoboStack/ros-noetic for ROS1 and https://github.com/RoboStack/ros-foxy for ROS2 (both are still kind of experimental). This repos effectively build a sort of "secondary" distribution of the ROS packages on the top of conda-forge, taking the necessary metadata from https://github.com/ros/rosdistro .

This is a "secondary" distribution in the sense that is not a distribution that builds the complete software stack, but just a layer of packages on a top of another existing distribution, similar to how bioconda (https://bioconda.github.io/) is built on top of conda-forge, or the ROS Buildfarm packages are a secondary distribution on the top of the official repositories of Ubuntu. The main difference w.r.t. official Ubuntu repositories is that with conda-forge is much easier and fast to add ROS-independent packages directly in the main conda-forge repository. In my previous comment I was referring to adding the ROS-independent tesseract core in conda-forge, for which (if I am not mistaken) all the required dependencies support Windows. Then, at the RoboStack level we are still sorting out how to deal with packages that are in conda-forge but are also release in the ROS Buildfarm (see https://github.com/RoboStack/ros-noetic/issues/20), but I think for packages such as tesseract it would be doable to just skip their build.

[johnwason]

I am looking at this package as an example:

https://github.com/conda-forge/ros-roscpp-feedstock

The package builds the library from source rather than using a pre-build ROS binary, so I don't think there is an ABI issue.

https://github.com/conda-forge/ros-roscpp-feedstock/blob/master/recipe/build.sh

This recipe doesn't have a bld.bat file, so it can't be built on Windows.

[wolfv]

Hi @johnwason thanks for looking at conda!
Indeed, our original ROS 1 packages on conda-forge did not build on Windows. However, we have started our own "channel" where we upload ROS packages, and build them on Azure Pipelines (very similar to how conda-forge operates).

You can find the channel on Anaconda.org here: https://anaconda.org/RoboStack/repo

As you can see, we have desktop-full for Windows, Linux (x64 and ARM64) and OS X.

These packages are built from here: http://github.com/robostack/ros-noetic and the build scripts can be found in the build_... branch: https://github.com/RoboStack/ros-noetic/tree/buildbranch_win

The build logs can be found here: https://dev.azure.com/roboforge/ros_pipelines/_build

So this was just a small overview over our current, ROS specific efforts. Due to how ROS & ROS distros work, we found this single-repo approach for build script generation simpler vs. maintaining many independent feedstocks. In that sense, the ros-*-feedstocks on conda-forge can be seen as deprecated.

However, we actively maintain the lower-level libraries on conda-forge: PCL, Ogre, Gazebo, FCL, ignition libraries, colcon, catkin_tools,... and we build purely on top of conda-forge. So I think for tesseract it would be awesome if it goes into conda-forge!
The only issue is that we can (currently) only put the non-ros dependent parts on conda-forge (otherwise we'd need to depend on the robostack channel).

I'd be very excited tesseract gets a PR to staged-recipes and I would be happy to help with the recipe in that PR!

[johnwason]

Thanks @wolfv

Currently the core tesseract, tesseract_planning, and tesseract_python don't depend on ROS. There is a separate tesseract_ros repo that does. @Levi-Armstrong do you plan on using one of the main channels or creating a ROS Industrial specific channel?

I am currently the technical lead on a team developing an open-source teach pendant based on Python, Tesseract, and Robot Raconteur, among other dependencies. My primary focus right now is getting Tesseract integrated into this project and find a way to easily deploy binaries to end users. My plan was originally to deploy on PyPi or docker, but I am thinking that using anaconda may be a better option if we can get dependencies with consistent ABI versions relatively easily. Having ROS available through anaconda would also make things much easier since then we don't need a system install. Currently the development of the teach pendant is pretty scattered, and we are beginning the effort to pull everything into the main organization repositories. I've created an issue there to discuss for that project: pyri-project/pyri-core#2

[wolfv]

That sounds great @johnwason! Using the conda constructor, you could even create a single-file installer for the project.

Does anyone of you want to start a PR to staged recipes? Otherwise I can look into it.

[johnwason]

@wolfv I am looking at the RoboStack GitHub. How does vinca select which packages to build? If tesseract is released to ROS, would it automatically pull the packages into RobotStack? Is it possible to use a catkin tools workspace with conda and have it build separate conda packages for each ROS package using vinca with the GitHub source repos as upstream?

[wolfv]

We select packages in the vinca.yaml files (https://github.com/RoboStack/ros-noetic/blob/master/vinca_linux_64.yaml). We use rosdistro tools to figure out all dependencies and create recipes where necessary.

If there are released tesseract versions into ROS, we can just select them in this vinca file and we'd get a recipe for them, yes.

Yes, basically that's possible and mostly what we're doing here (instead of catkin-tools we just use cmake etc).

However, if tesseract is just cmake based and doesn't need anything ROS specific (at least for some packages), then one can just write a recipe and build script manually. For example, a libignition recipe like this one https://github.com/conda-forge/libignition-common-feedstock/tree/master/recipe could be a good starting point?

[wolfv]

PS this is the source for vinca if you're curious: https://github.com/robostack/vinca

When you have a package.xml you can also try running vinca with a single package.xml (no rosdistro release necessary):

vinca -p package.xml -d ~/Programs/ros-noetic/

this generates a recipe and build scripts in place (very experimental, not great for general use just yet).

Additionally there are a bunch of complications (our version of vinca generates build scripts for boa which is a slightly enhanced version of conda-build, so you need to run boa build . etc...)

This is the recipe I get for tesseract_common

package:
  name: ros
  version: 2021.01.26

source:
  - path: ''
    folder: ros-noetic-tesseract-common/src/work

build:
  number: 0

about:
  home: https://www.ros.org/
  license: BSD-3-Clause
  summary: |
    Robot Operating System

extra:
  recipe-maintainers:
    - ros-forge

outputs:
  - package:
      name: ros-noetic-tesseract-common
      version: 0.1.0
    about:
      home: https://www.ros.org/
      license:
        - Apache 2.0
      summary: Contains common macros, utils and types used throughout
    extra:
      recipe-maintainers:
        - robostack
    build:
      number: 0
      script:
        sel(win): bld_catkin.bat
        sel(unix): build_catkin.sh
    requirements:
      build:
        - "{{ compiler('cxx') }}"
        - "{{ compiler('c') }}"
        - ninja
        - sel(unix): make
        - cmake
      host:
        - cmake
        - eigen
        - console_bridge
        - tinyxml2
        - eigen
        - console_bridge
        - tinyxml2
        - gtest
        - lcov
      run:
        - eigen
        - console_bridge
        - tinyxml2
        - ros-noetic-catkin
        - console_bridge
        - tinyxml2

Well, I hope this was not too confusing. If yes, then sorry!

[johnwason]

I tried building in a conda environment. Colcon is included in conda-forge, so it was pretty easy to get a workspace set up and begin the build. It looks like I am getting older versions of the various packages. The Anaconda website shows newer versions, but the install instructions are still pulling older versions. For instance, Bullet 3.0.3 is listed (https://anaconda.org/conda-forge/bullet), but I am getting a 2.x version when installed. Am I doing something wrong? Here are the build instructions I used (on Windows):

conda create -n tesseract_build python=3.8
conda activate tesseract_build
call conda install -c conda-forge boost colcon-common-extensions eigen tinyxml2 console_bridge jsoncpp octomap assimp -y
call colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release -DINSTALL_OMPL=ON -DINSTALL_OMPL_TAG=main -DBUILD_IPOPT=OFF -DBUILD_SNOPT=OFF -DINSTALL_FCL=ON -DINSTALL_BULLET=ON

[wolfv]

@johnwason we had to pull the bullet version because bullet (cpp) was never properly released, only the PyPI package. We need to do some work on the bullet-feedstock to get a recent bullet version to conda-forge.

Do you require a very recent version of bullet? I think ubuntu and others also ship an old version for the C++ part.

[johnwason]

Tesseract requires recent versions of quite a few packages. Because the versions in distributions tend to be old, it provides a way to build them from source:

https://github.com/ros-industrial-consortium/tesseract_ext

https://github.com/ros-industrial-consortium/trajopt_ros/tree/master/trajopt_ext

The problem with this method is that it leads to multiple versions of the same library in the environment, which can lead to DLL hell. I had hoped that conda-forge would be more up to date but most of the libraries that are being installed are still older versions. I there a channel that has more up to date libraries?

[wolfv]

conda-forge is a community maintained distribution. Lot's of updates are happening semi-automatically with bots pushing new versions (as you can see on the bullet-feedstock). Most of the time a little human interaction is required to merge the automatically created PR's, but even that can be automerged. So usually conda-forge has the latest versions.

Unfortunately bullet followed a bit of an odd scheme, which is why there needs to be a bit of an effort to get the conda-forge package onto the latest version.

I can try to look into bullet this week (it's a bit complicated because the package needs splitting of the c++ and python component).

What other dependencies do you find that are not up to date? If you have time & motivation you can look at the feedstocks.

PS. looks like ompl also needs a bump (conda-forge/ompl-feedstock#7)

[johnwason]

@Levi-Armstrong has mentioned creating a ROS-I or SwRI channel, so that may be necessary to get everything up to date. The build was still not successful even with the use of the ext libraries. I have run out of time for now to work on this so I can't dig into it any further.

[wolfv]

sure, the approach we have with RoboStack is that our base packages have to come from conda-forge, and everything ros-specific should live in the robostack channel. So we do contribute quite a lot to conda-forge, as well as related software (ignition/gazebo, dartsim, robotics-toolbox ...).

I can recommend a similar setup to you. Having your own channel is similarly easy. Just create one on Anaconda.org and push from github actions or similar.

[johnwason]

The class_loader package, while claiming to be ROS independent seems to require either catkin or ament. This is making it impossible to build using conda-forge.

[Levi-Armstrong]

Yea, I recently noticed this and plan to switch to using boost dll. Do you have any concerns with this?

[johnwason]

I haven't used either class_loader or boost.dll so I don't have an opinion on either

[gavanderhoorn]

@johnwason wrote:

The class_loader package, while claiming to be ROS independent seems to require either catkin or ament. This is making it impossible to build using conda-forge.

I haven't checked myself, but seeing as Catkin and Ament are basically CMake extensions (similar to ros_industrial_cmake_boilerplate) and packages can be built using mkdir build && cd build && cmake .. (provided the environment is setup correctly), what makes that impossible to build with Anaconda?

It seems @wolfv et al are able to build many other packages which depend on Catkin/Ament.

@Levi-Armstrong wrote:

Yea, I recently noticed this and plan to switch to using boost dll. Do you have any concerns with this?

Why not try the class_loader maintainers to get rid of the Catkin/Ament dependency?

If they don't want to or can't, then migrate to something else.

[wolfv]

I have just released ompl 1.5.0 to conda-forge, and I am in the process of updating it to 1.5.2

I'll try to look into bullet asap as well.

Regarding catkin, we could probably have a ros-independent catkin on conda-forge (as well as a ros-independent class loader). But the way these things are released they are often somewhat tied to the ros-distribution ...

You can also release your packages into the robostack (we have a mechanism to add packages that are not part of a ros distribution). And there you could rely on e.g. ros-noetic-catkin

[wolfv]

I have been working on an updated bullet 3 recipe here: https://github.com/conda-forge/bullet-feedstock/pull/28/files

Feel free to let me know if you have comments / suggestions or help! Would be much appreciated.

[johnwason]

@gavanderhoorn there are some ROS packages on conda-forge, but they don't appear to be maintained and aren't available for Windows. I am trying to avoid adding additional channels if I can avoid it. The tesseract python library shouldn't require ROS. The objective is to eventually provide a PyPi wheel with everything statically linked, so the goal is to remove dependencies that will prevent making the self contained package.

Fixing the class_loader package may be possible. It is not clear why it is using catkin.

[johnwason]

@wolfv I've found a similar packaging version problem when trying to install Gazebo on linux-64 using conda-forge.

conda-forge/gazebo-feedstock#79

[johnwason]

@traversaro thanks I will keep an eye on that.

[johnwason]

Here are the issues that need to be cleaned up in the feedstock:

• Python 3.9 solving environment fails johnwason/tesseract-robotics-superpack-feedstock#1
• Solving environment hangs when OMPL is included on Linux johnwason/tesseract-robotics-superpack-feedstock#2
• Split superpack into individual packages johnwason/tesseract-robotics-superpack-feedstock#3
• FindLZMA failing on GitHub Actions johnwason/tesseract-robotics-superpack-feedstock#4
• Use Bullet double precision floating point johnwason/tesseract-robotics-superpack-feedstock#5
• Submit patches to upstream johnwason/tesseract-robotics-superpack-feedstock#6

[Levi-Armstrong]

@traversaro Do you know if there are plans to resolve this issue @johnwason outlines in this issue?

[traversaro]

@traversaro Do you know if there are plans to resolve this issue @johnwason outlines in this issue?

It is difficult to have plans for fixing a issue you are not aware of. :D

Indeed, I had no idea that problem was present at all, Probably what is happening for our builds of osqp is that the shared library does not export any symbol, so osqp.lib (imported library) is not generated, and so osqp.lib is mistaken for an imported library but it is actually the static library. That means we have quite a bug in the Windows binaries we generate at https://github.com/conda-forge/libosqp-feedstock . I will try to open an issue and fix the issue in the next days, if in the meanwhile you want to open an issue in https://github.com/conda-forge/libosqp-feedstock or even better upstream, please go on, thanks!

[Levi-Armstrong]

@traversaro Thanks for the support. I have created an issue on both OSQP and QDLDL.

[johnwason]

More issues with the conda package:

conda-forge/jsoncpp-feedstock#30

johnwason/tesseract-robotics-superpack-feedstock#7

[traversaro]

@traversaro thanks I will keep an eye on that.

We released osqp-eigen in conda-forge (see https://github.com/conda-forge/osqp-eigen-feedstock), you can probably drop the use of robotology channel.

FYI @GiulioRomualdi

[traversaro]

@traversaro Thanks for the support. I have created an issue on both OSQP and QDLDL.

At the conda-forge level, this was fixed by conda-forge/libosqp-feedstock#6 and by https://github.com/conda-forge/libqdldl-feedstock/blob/master/recipe/fix_build_shared_libs_and_windows_shared.patch .

[johnwason]

Thanks @traversaro I will take a look at these fixes.

@Levi-Armstrong are you going to create another release for the tesseract package?

[johnwason]

I am getting another strange conda build error:

https://github.com/johnwason/tesseract-robotics-superpack-feedstock/runs/3129632265?check_suite_focus=true#step:6:2512

vtk seems to have its own FindLZMA.cmake module used to find the library.

I was able to get around it by hard coding the LZMA_LIBRARY variable in the bld.bat script.

[johnwason]

I am seeing another build error for Python 3.9 on Windows. For some reason I am getting an outdated version of bullet, among other packages for Python 3.9 but not Python 3.8.

bullet:                     2.89-py39h2e25243_2              conda-forge

This should be bullet 3.17.

https://github.com/johnwason/tesseract-robotics-superpack-feedstock/runs/3130053343?check_suite_focus=true#step:6:928

@wolfv

[johnwason]

I uploaded new tesseract packages to conda. This update is mainly to deal with dependency changes, and doesn't update tesseract itself. Currently Python 3.8 and 3.9 are available for Linux, with Python 3.8 available for Windows.

[Tobias-Fischer]

There is a bug in the bullet feedstock. If you add pybullet and bullet-cpp as dependencies instead of bullet, it should work.

Error:

  - package bullet-3.17-h57928b3_0 requires pybullet 3.17 py38h60cbd38_0, but none of the providers can be installed

Note that bullet wants py38 instead of py39. Only a single bullet package is built, it should instead have different build numbers per python version

/cc @traversaro

[wolfv]

I am kinda responsible for the (new) bullet package.
I tried to split the C++ package and the Python package.

Let me investigate a bit.

[traversaro]

Only a single bullet package is built, it should instead have different build numbers per python version

Indeed, having a single package would be ok, but unfortunatly then this single package depend on the specific Python version (see this part from the index.json):

{
  "arch": "ppc64le",
  "build": "ha3edaa6_0",
  "build_number": 0,
  "depends": [
    "bullet-cpp 3.17 hc8de3aa_0",
    "pybullet 3.17 py37hc8de3aa_0"
  ],
  "license": "Zlib",
  "name": "bullet",
  "platform": "linux",
  "subdir": "linux-ppc64le",
  "timestamp": 1620465033161,
  "version": "3.17"
}

[wolfv]

argh, ok. I see the problem, that sucks.

[wolfv]

right, ok, one solution would be to depend on only bullet-cpp -- or pybullet.
I'll file an issue on the feedstock.

[johnwason]

I am confused, why are there three different bullet packages? Isn't this going to cause a conflict?

[wolfv]

there is pybullet and bullet-cpp. both are actually built quite differently, and strictly speaking pybullet doesn't depend at all on bullet-cpp. It's also really difficult to properly package bullet. I tried for a while but had to give up because one would have to completely rewrite the build system.

py-bullet is built from a setup.py and statically links & vendors a lot of stuff.

bullet-cpp is built from a CMake and properly installs stuff but is not linked by pybullet (IIRC).

So there should not be any conflicts (except for this case with the wrong bullet "meta-package" that should get both, pybullet + bullet-cpp).

[wolfv]

I just wanted to link some past discussion from the issue tracker, but it's closed on bullet (https://github.com/bulletphysics/bullet3#issues) 🤷

[johnwason]

Thanks @wolfv and @Tobias-Fischer, switching to bullet-cpp package seems to have fixed the issue. The conda package is now working for Python 3.8 and 3.9 on Windows and Linux.

https://anaconda.org/Tesseract-Robotics/tesseract-robotics-superpack

[johnwason]

I tried to install ros-noetic-rospy from robostack after installing tesseract-robotics-superpack and got a large number of conflicts. Are conda-forge and robostack incompatible?

[johnwason]

Here is the conflict output:

tesseract_rospy_conda_conflict.txt

[Tobias-Fischer]

We are currently in the process of migrating our RoboStack packages to tinyxml2=9, which recently happened on conda-forge. Once this migration will have happened, we will be able to install the tesseract-robotics-superpack and ros-noetic packages side-by-side.

[johnwason]

The PyRI Open Source Teach Pendant was the main motivation for releasing Tesseract on Conda. See #629

[johnwason]

I am having another weird ompl dependency problem. See johnwason/tesseract-robotics-superpack-feedstock#9