Jacob Perron

Results 258 comments of Jacob Perron

Windows CI: [![Build Status](https://ci.ros2.org/buildStatus/icon?job=ci_windows&build=15681)](https://ci.ros2.org/job/ci_windows/15681/) Edit: we can build on Windows now, but the tests are failing. The output isn't particularly helpful.

* Linux [![Build Status](http://ci.ros2.org/buildStatus/icon?job=ci_linux&build=16224)](http://ci.ros2.org/job/ci_linux/16224/) * Linux-aarch64 [![Build Status](http://ci.ros2.org/buildStatus/icon?job=ci_linux-aarch64&build=10849)](http://ci.ros2.org/job/ci_linux-aarch64/10849/) * Windows [![Build Status](http://ci.ros2.org/buildStatus/icon?job=ci_windows&build=16579)](http://ci.ros2.org/job/ci_windows/16579/)

Services are supported if you configure the domain bridge in code (not YAML, which is why this issue exists). Unfortunately, we don't have a good example of bridging services, though...

@aprotyas Thanks for working on this :) I've retargeted the PR to `foxy` (which is based on `galactic`).

I've also pushed a commit to your branch to make CI target Foxy (cce4273).

This package was initially developed with ROS Galactic in mind, and I'm not sure if it ever successfully built for Foxy. I'm not sure I have the time to investigate...

@aprotyas If we go back into the commit history of the domain_bridge, you'll find that we used to have a copy of `rclcpp::GenericPublisher` and `rclcpp::GenericSubscription` in this repository (since it...

@jtbandes This dropped off my radar, sorry for the late reply. > One thing I don't understand is why this error appears for rosapi, but not rosbridge_library. I would expect...

Another workaround to consider is renaming your Python package such that it does not match the package name.

@hidmic If I understand your proposal, this still puts the responsibility on the user to avoid install collisions if they are installing interfaces and custom Python code to the same...