search

ros-infrastructure / catkin_pkg

Standalone Python library for the catkin build system.
https://github.com/ros/catkin
Other
47 stars 91 forks source link

Drop package naming convention warnings for non-catkin packages. #161

Closed mikepurvis closed 7 years ago

mikepurvis commented 7 years ago

Packages which have been third-party-released into the ROS ecosystem shouldn't be subject to as stringent naming conventions. Would a patch be welcome which allows dashes when the build type is non-catkin?

dirk-thomas commented 7 years ago

The current restriction ensures that package names are unique and can be released without a collision. If foo_bar as well as foo-bar are valid package names they will collide when being released as Debian packages.

Since third-party packages don't have a manifest file upstream they can easily use the underscore variation in the manifest. So it is not preventing them from being packaged at the moment.

But I agree to your point that we should not enforce conventions on packages if not necessary. Therefore I am not sure if the pro outweighs the con. Let see what other think: @ros-infrastructure/ros_team

mikepurvis commented 7 years ago

The situation for us is that we have internal packages which have <depend>foo-bar</depend> in their manifest, and that has traditionally been a package that we've released (or imported) as a standalone deb. However, now for various reasons we are "third party releasing" some of these packages and building them as part of our distribution bundle, dropping the dependency on the standalone deb package.

This applies particularly to Python packages, in conjunction with catkin_tools_python. It feels awkward and wrong to visit a consuming package and change a dependency from python-bar-baz to python_bar_baz just to comply with this naming requirement. The canonical name of such a dep has long been established as the "debian" name with dashes, and the consuming package shouldn't care whether it's ultimately being provided by a system package or a catkin workspace package.

mikepurvis commented 7 years ago

It's a fairly trivial change— I've opened PR #162, so let's take the discussion there.