Add support for version_eq

[yotabits]

According to https://www.ros.org/reps/rep-0127.html#build-depend-multiple
Pacakge.xml supports version for dependencies.

I made an attempt to add support for version_eq here

with the following package.xml:

<?xml version="1.0"?>
<package format="2">
  <name>foo</name>
  <version>0.0.0</version>
  <description>The foo package</description>
  <maintainer email="tkostas@todo.todo">tkostas</maintainer>
  <license>TODO</license>

  <buildtool_depend>catkin</buildtool_depend>

  <depend version_eq="0.6.5-0bionic.20210112.183245">tf2_ros</depend>

</package>

Modified rosdep give me this output

rosdep install --from-paths ~/rosdep_ws/src/ --ignore-src -r -y --reinstall -y -s
#[apt] Installation commands:
  sudo -H apt-get install -y ros-melodic-tf2-ros=0.6.5-0bionic.20210112.183245

Even my approach is very clumsy it seems to work to some extent. Now I would like to make it more robust.

To do so I think it will necessitate some refactoring of the existing code, here is what I can think of:

• Keep a generic installer class working similarly to the actual one
• For installers supporting versions as they manages versions differently we will probably need a class per installer.
• An installer object will manage a list of dependency objects specific to that installer
• It would be probably a good idea to carry objects in the return value of resolve_all (resolution_flat) (in Rosdeplookup.resolve_all()) something like

[ (installer_name, [Dependecy_object_with_additions]) ]

instead of what we have atm

[ (installer_name, [string_to_install_by installer] )]

Does this sound like a reasonable approach? what would you suggest?

[yotabits]

@cottsay Can I please have your feedback on this?

[asasine]

Has there been any update on this? It would be great to be able to version rosdep rules that are themselves pip packages.

[cottsay]

I think we need to answer some pretty fundamental questions like what to do if a different version is already installed, or if the version specified isn't available but another is. It can be even more complicated when you consider that a project's version number can be different from a package's version number - concepts like debinc and packaging epoch numbers complicate this conceptually.

Python packages add yet another layer of complexity because pip can't always differentiate whether an installed package was provided by a system package (deb/rpm) or was installed by pip. If a system package for a python dependency is already installed but not at a sufficiently new version, should pip try to install a more up-to-date version that would occlude the system package, possibly breaking other downstream system packages in the process?

[duartecoelhomovai]

Please do it. I've a tool used for compiling and generating debians out of a ros package. But unfortunately i can not guarantee the dependency tree at build time, because it installs the latest.

Please consider having the rosdep use version_eq.

[duartecoelhomovai]

On the release of my mobros tool i've enabled the installation of build dependencies with versions for apt. Hopefully will help you guys

[duartecoelhomovai]

For the people that want to use it, here it goes. https://github.com/MOV-AI/mobros-build-system

Theres a quickstart script also. Simply execute it in the root of your repository.

wget -qO - https://movai-scripts.s3.amazonaws.com/ros-build2.bash | bash

[asasine]

I think we need to answer some pretty fundamental questions like what to do if a different version is already installed, or if the version specified isn't available but another is. It can be even more complicated when you consider that a project's version number can be different from a package's version number - concepts like debinc and packaging epoch numbers complicate this conceptually.

Python packages add yet another layer of complexity because pip can't always differentiate whether an installed package was provided by a system package (deb/rpm) or was installed by pip. If a system package for a python dependency is already installed but not at a sufficiently new version, should pip try to install a more up-to-date version that would occlude the system package, possibly breaking other downstream system packages in the process?

What do you think of letting the underlying package manager decide/handle this entirely? Some package managers allow multiple versions to be simultaneously installed, either indirectly/transiently or directly (e.g., package aliases in NPM).

[duartecoelhomovai]

I think we need to answer some pretty fundamental questions like what to do if a different version is already installed, or if the version specified isn't available but another is. It can be even more complicated when you consider that a project's version number can be different from a package's version number - concepts like debinc and packaging epoch numbers complicate this conceptually.
Python packages add yet another layer of complexity because pip can't always differentiate whether an installed package was provided by a system package (deb/rpm) or was installed by pip. If a system package for a python dependency is already installed but not at a sufficiently new version, should pip try to install a more up-to-date version that would occlude the system package, possibly breaking other downstream system packages in the process?

What do you think of letting the underlying package manager decide/handle this entirely? Some package managers allow multiple versions to be simultaneously installed, either indirectly/transiently or directly (e.g., package aliases in NPM).

APT does not allow a dependency tree that relies on dependencies that require old combinations. In this mobros tool i calculate all the candidates and provide the whole dependency tree as inputs (in an ordered matter) for apt not to calculate anything.
Also had to mess with the apt-policies to be able to let apt accept Mobros's decisions.