Open jpsamper2009 opened 6 years ago
mikaelarguedas
commented
6 years ago It looks like the feature requested is very similar to:
ament list_dependencies
Would you mind trying it out and comment here if any of you use cases is not covered by it?
Thanks!
dirk-thomas
commented
6 years ago I think having a command like ros2 pkg depends <package name> would be good. While ament_tools implements something similar a user might not even have that build tool installed. Also ament_tools is focusing on the packages in a workspace while this new command would cover all packages installed on a system.
ros2 pkg prefix <package_name>is supposed to output the prefix path of a package. However, it seems to alway return the path to the install folder (not sure if this is a bug).
Returning the install prefix of the package is not a bug but intentional. It allows you to construct the path to any artifact provided by that package. By appending share/<pkgname>/package.xml you will get the path to the manifest.
You can call the same functionality through the Python API directly: https://github.com/ros2/ros2cli/blob/5137887fa95bab1323f81a3ae6b1cd670e1f7fbd/ros2pkg/ros2pkg/api/__init__.py#L32
There's python libraries to parse xml files (e.g. xml.etree.ElementTree). I don't know ROS has a prefered library. If we want to give options for the different types of dependencies, we would just have a filter during parsing.
ament_package already provides the logic to parse the manifest (https://github.com/ament/ament_package/blob/30ec27ee5bec133bef51abd1f82b2c38c8d07cac/ament_package/__init__.py#L32) as well as provide a class which exposes all the information of a package (https://github.com/ament/ament_package/blob/30ec27ee5bec133bef51abd1f82b2c38c8d07cac/ament_package/package.py#L21).
jpsamper2009
commented
6 years ago @mikaelarguedas, that was the functionality I was looking for :), but I guess it would also be nice to have it in this context too (as Dirk said)
@dirk-thomas After reading about the package resource index, I figured out it wasn't a bug; ros2 pkg prefix is just more useful when you have multiple install locations. That being said, it looks like ament_package is not using the resource index for dependencies (except run_dependencies). Would it be better to have index_resources include a package_dependencies folder, and use that in the implementation of this feature?
mikaelarguedas
commented
6 years ago that was the functionality I was looking for :), but I guess it would also be nice to have it in this context too (as Dirk said)
Agreed, it would be nicer to have here under the pkg verb ala rospack. I just wanted to advertise that the functionality was available somewhere if you needed it right now :).
dirk-thomas
commented
6 years ago That being said, it looks like ament_package is not using the resource index for dependencies (except run_dependencies).
ament_package only parses the manifest and provides a object oriented interface to the data. When being used a package might not have been built yet and therefore the index doesn't exist at that time.
Would it be better to have index_resources include a package_dependencies folder, and use that in the implementation of this feature?
During the installation of a package we could generate resources for every dependency. That might especially speed up the recursive dependency search. Maybe start by parsing the manifest for now and maybe later switch to use the index as an internal optimization.
jpsamper2009
commented
6 years ago Sounds good.
On Aug 21, 2017, at 9:25 AM, Dirk Thomas notifications@github.com wrote:
That being said, it looks like ament_package is not using the resource index for dependencies (except run_dependencies).
ament_package only parses the manifest and provides a object oriented interface to the data. When being used a package might not have been built yet and therefore the index doesn't exist at that time.
Would it be better to have index_resources include a package_dependencies folder, and use that in the implementation of this feature?
During the installation of a package we could generate resources for every dependency. That might especially speed up the recursive dependency search. Maybe start by parsing the manifest for now and maybe later switch to use the index as an internal optimization.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Feature request
Feature description
It could be nice to have a tool to get the dependencies of a given package. Something like:
If we want to get fancier, we could also add options for different types of dependencies (build, exec, test, etc.). And if we want to get even fancier, we could add an option to get sub-dependencies (essentially calling ros2 pkg depends recursively). This could be a separate feature request, though.
Implementation considerations
My first instinct would be to use the information encoded in the package.xml file. This would require two steps: 1) Finding the package.xml for the desired package
ros2 pkg prefix <package_name>is supposed to output the prefix path of a package. However, it seems to alway return the path to the install folder (not sure if this is a bug). 2) Parsing the file to extract the relevant information.