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?
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
Using
conda env create -f environment.ymlto setup the environment, the generated cmake files identifylibconsole_bridge.so.0.4as being required. As best as I can tell that stems from the dependency identified inclass_loader'spackage.xmlfile, specifically line 23. On Ubuntu 18.04 this package does indeed currently point to a 0.4 version of thelibconsole_bridgelibrary however the development (and runtime) packages are not installed on this system. This was verified by attempting to install withapt-get install libconsole-bridge-dev libconsole-bridge0.4and seeing it confirm if these should be installed. From theconda env createit is installing the latest release ofconsole_bridge, in this case 1.0.0. We are able to work around this issue by includingconsole_bridge=0.4.4which 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 includeconsole_bridgein theenvironment.ymlfile 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_loaderby reviewing an strace ofconda env createas it wasn't clear where this dependency was coming from. Using ldd, it confirmed thatlibclass_loader.sowas linked against console_bridge 0.4. Again usingapt-get installI 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 freezethat 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?