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

Library/Dependency Detetction; Bug? #161

Open
bmagistro opened this issue Jun 10, 2020 · 0 comments
Open

Library/Dependency Detetction; Bug? #161

bmagistro opened this issue Jun 10, 2020 · 0 comments

Comments

@bmagistro
Copy link

Have possibly identified a bug in dependency detection. I am not sure if this should be filed against this library, catkin, and/or conda.

Environment:
Docker image w/ Ubuntu 18.04
Miniconda 4.8.2 (python 3.7)
ROS Melodic

environment.yml

name: venv
channels:
  - conda-forge
dependencies:
  - python=3.6
  - pip
  - numpy
  - ros-core
  - ros-actionlib
  - ros-dynamic-reconfigure
  - rosinstall_generator
  - rosinstall
  - catkin_tools
  - pytorch
  - numexpr

Using conda env create -f environment.yml to setup the environment, the generated cmake files identify libconsole_bridge.so.0.4 as being required. As best as I can tell that stems from the dependency identified in class_loader's package.xml file, specifically line 23. On Ubuntu 18.04 this package does indeed currently point to a 0.4 version of the libconsole_bridge library however the development (and runtime) packages are not installed on this system. This was verified by attempting to install with apt-get install libconsole-bridge-dev libconsole-bridge0.4 and seeing it confirm if these should be installed. From the conda env create it is installing the latest release of console_bridge, in this case 1.0.0. We are able to work around this issue by including console_bridge=0.4.4 which forces the env to have a version that matches that of the package that would be provided by the host system. Previously we did not explicitly include console_bridge in the environment.yml file but allowed the dependencies of other components to pull this in. Explicitly including it like this seems very likely to break when the host repositories are updated.

The library was tracked back to class_loader by reviewing an strace of conda env create as it wasn't clear where this dependency was coming from. Using ldd, it confirmed that libclass_loader.so was linked against console_bridge 0.4. Again using apt-get install I can confirm that class_loader was not installed via the system package manager.

Is there something we should be doing when installing in this manner to ensure the correct versions are included? Is there the equivalent of pip freeze that can generate a full environment file with versions for every component to lock things in place until we choose to do an upgrade or change a component?

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

1 participant