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.

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

Make filenames to be used as ignore markers configurable #307

Conversation

janstrohbeck
Copy link
Contributor

catkin_pkg ignores packages that include one of {CATKIN_IGNORE, COLCON_IGNORE, AMENT_IGNORE}. For catkin_tools (which utilizes functions from catkin_pkg), I would like to implement a behavior such that it will only ignore packages that include CATKIN_IGNORE (and not those that have COLCON_IGNORE/AMENT_IGNORE). This PR does not change any functionality, it only makes the set of ignore markers configurable via a keyword argument. Link to catkin_tools PR: catkin/catkin_tools#688

@nuclearsandwich
Copy link
Contributor

At first I wasn't too bothered by this PR and I even just pushed up some basic test cases exercising it. But as I was getting ready to approve I started wondering what use cases there are for making this configurable. The inciting case was helpfully described in the accompanying catkin_tools pr which involves using a shared workspace with ROS 1 and ROS 2 packages and I'm not sure that I could ever endorse or recommend sharing a source space with two different build tools like catkin_tools and colcon. Once tests and linters are passing I think I default to accepting this change because it doesn't break anything in the default tooling but I'd like to get other opinions as well.

@nuclearsandwich nuclearsandwich requested a review from cottsay March 1, 2022 05:19
Copy link
Contributor

@nuclearsandwich nuclearsandwich left a comment

Choose a reason for hiding this comment

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

Approved with some hesitation about whether switching any existing tooling to use this option or the enabled use case of running a mixed ROS and ROS 2 source workspace with different build tools should even be encouraged.

Copy link
Member

@cottsay cottsay left a comment

Choose a reason for hiding this comment

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

I'm lukewarm about whether your driving use case is actually a good idea, but this PR does no harm and provides API flexibility that could be useful.

@cottsay cottsay merged commit 357eba1 into ros-infrastructure:master May 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants