Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Define the term "ROS package" #265

Closed
wants to merge 2 commits into from
Closed

Define the term "ROS package" #265

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2a42cbb
Define the term "ROS package"
rotu May 20, 2020
307182c
Update rep-0149.rst
rotu May 20, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion rep-0149.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
REP: 149
Title: Package Manifest Format Three Specification
Title: ROS Package Manifest Format Three Specification
Author: Dirk Thomas
Status: Final
Type: Standards Track
Expand Down Expand Up @@ -51,6 +51,12 @@ Motivation
This REP covers three separate topics which are described in the following
subsections.

A source tree containing a conformant ``package.xml`` file in its root
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is likely incorrect. I think Dirk will come over and mention that the package.xml has nothing to do with ROS, it has to do with catkin / ament.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the term "ROS Package" has to be this broad for the following statement to be correct:

<build_depend> (multiple)

Declares a rosdep key or ROS package name that this package requires at build-time. For system packages, the rosdep key will normally specify the "development" package, which frequently ends in "-dev".

This REP does use the term "catkin package", which seems to mean "a ROS package that uses build_type = catkin"

Copy link
Contributor

@SteveMacenski SteveMacenski May 20, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's an argument to remove ROS in those instances, actually. This clarifications you added seem to be to be largely unnecessary and probably incorrect. I think we should correct those errors rather than clarify the potential error for the rest of the doc

Copy link
Contributor Author

@rotu rotu May 20, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think "ROS package" is unambiguous and defined exactly how it is used in the document. After all this is a "ROS Enhancement Proposal". It might be helpful to think of the "ROS" qualifier as "interoperable with the ROS community and associated tools".

I don't think it's sensible to just drop the qualifier. "Package" a very overloaded term, and we need a way to disambiguate between these things are often associated with ROS packages:

For instance rosidl_generator_c:

  • Is contained within a ROS package named rosidl_generator_c
  • Is built using a CMake project named rosidl_generator_c
  • Installs a CMake config-file package named rosidl_generator_c
  • Installs a Python import package named rosidl_generator_c

directory is called a "**ROS package**," regardless of whether it uses or is
used by ROS.
When unambiguous from context, this may simply be referred to as a
"**package**".

Dependency groups
-----------------

Expand Down