Open yotabits opened 3 years ago
@cottsay Can I please have your feedback on this?
Has there been any update on this? It would be great to be able to version rosdep rules that are themselves pip packages.
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?
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.
On the release of my mobros tool i've enabled the installation of build dependencies with versions for apt. Hopefully will help you guys
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
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).
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.
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
herewith the following package.xml:
Modified
rosdep
give me this outputEven 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:
resolution_flat
) (in Rosdeplookup.resolve_all()) something likeinstead of what we have atm
Does this sound like a reasonable approach? what would you suggest?