introduce include elements

[vcstools]

introduce include elements

[meyerj]

Are there any updates for this issue? We started to structure stuff with rosws at Team Hector Darmstadt a couple of weeks ago. Although my knowledge about the background and design goals of rosws is limited, I would also like the idea of having an include feature and found that thread while searching for possible solutions at the web.

When working with different projects that partially depend on each other, including the rosinstall files of other workspaces would allow to define kind of dependencies between workspaces and avoid having duplicate working copies for the same ROS distro being distributed throughout the file system. I am thinking at the following use case:

~/ros
 |- robot_a_specific_workspace
 |    |- .rosinstall   <---------------------------|
 |    |- driver_stack                              |
 |- slam_workspace                                 |
 |    |- .rosinstall   <---------------------------|
 |    |- hector_slam                               |
 |- demo_application                               |
      |- .rosinstall  -----------------------------|
      |- demo_application_using_slam_with_robot_a

The demo_application requires the robot-specific stacks (drivers, launch files, etc.) for robotA and some features like SLAM or navigation, that could also be required for different robots or applications.

As the setup.sh script generated by rosws overwrites the ROS_PACKAGE_PATH, it is not possible to source one workspace after the other. Adding the setup.sh file of another workspace as a setup-file entry type would also reset the package path and currently fails with the following error message when sourcing the setup.sh:

Traceback (most recent call last):
  File "<stdin>", line 6, in <module>
AttributeError: 'NoneType' object has no attribute 'split'

Using rosws merge in the demo_application would require manual synching if one of the dependent workspaces changes and it is not possible to pull updates for all required sources by just running rosws update in the demo_application workspace. And last but no least the demo_application could checkout its own working copies by merging the source rosinstalls instead of the workspaces, but this is what I would like to avoid. Is there any other possibility that I currently miss?

What are the issues with includes mentioned in the last paragraph? The check that only one setup-file exports a ROS_ROOT should also be possible while traversing the included workspaces.

The semantics of including other rosinstall files I would expect is something between rosws merge and doing a pure substitution by the contents of the included file: Existing working copies in an included workspace are reused as with a merge and not checked out again, as it would be the case with a pure substitution. rosws update, status and others could either follow included workspaces as with SVN externals (obviously with the drawback of influencing the other workspaces) or only work on the local workspace it is called for. Identical entries in different rosinstall files should be merged if they are not in conflict and point to same path (e.g. the ROS base installation setup file).

[tkruse]

The current status of this issue is that of a sleeping dog, best not to waken up :-).
Obviously you can fork the rosinstall project and add such a feature, but if many users would prefer to have that feature, we'd be happy to put in the effort. Currently it seems however that users can still do okay using the limited features currently provided.

With the last release the ROS_PACKAGE_PATH should be extended from other setupfiles mentioned in the .rosinstall rather than overwritten (though you have to call rosws regenerate to change the setup file to make it so in existing workspaces). The python error is a bug, thanks for reporting it, fixed in #55. Using latest from master this should be fine (you can also manually patch your setup.sh file.

[meyerj]

Thanks for the quick response! If adding other workspace's setup files is fine and the ROS_PACKAGE_PATH is not overwritten in those cases, this will be fine for us for now. Nevertheless, I think adding a rosws include or rosws depend command or something similar would be a valueable enhancement of rosws.

[tkruse]

Note that rosws is probably at it's end of life soon, because the ROS
ecosystem is supposed to move towards the catkin build system, where the
ROS_PACKAGE_PATH is not used anymore, and users should use a single source
folder for all projects being compiled as one.
wstool is the replacement then for rosws, where it does exactly the same
things as rosws for VCS operations, but does not create any setup.*sh files
(all that is organized by catkin, then). In light of this, don't get your
hopes up for an include element / command.

On Fri, Feb 1, 2013 at 12:18 AM, Johannes Meyer [email protected]:

Thanks for the quick response! If adding other workspace's setup files is
fine and the ROS_PACKAGE_PATH is not overwritten in those cases, this will
be fine for us for now. Nevertheless, I think adding a rosws include or rosws
depend command or something similar would be a valueable enhancement of
rosws.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-12971989.

[dirk-thomas]

Closing since the repository is about to be archived: see #126.