Add ros2-easy-test pip key to rosdep.

[vik748]

Please add the following dependency to the rosdep database.

Package name:

ros2-easy-test

Package Upstream Source:

https://github.com/felixdivo/ros2-easy-test

Purpose of using this:

This dependency allows testing for ros2 packages without a lot of boiler plate. It make a very useful addition to the rosdep database.

Distro packaging links:

Links to Distribution Packages

• pip:
  • https://pypi.org/project/ros2-easy-test/
• Debian: https://packages.debian.org/
  • not available
• Ubuntu: https://packages.ubuntu.com/
  • not available
• Fedora: https://packages.fedoraproject.org/
  • not available
• Arch: https://www.archlinux.org/packages/
  • not available
• Gentoo: https://packages.gentoo.org/
  • not available
• macOS: https://formulae.brew.sh/
  • not available
• Alpine: https://pkgs.alpinelinux.org/packages
  • not available
• NixOS/nixpkgs: https://search.nixos.org/packages
  • not available
• openSUSE: https://software.opensuse.org/package/
  • not available
• rhel: https://rhel.pkgs.org/
  • not available

[clalancette]

CI is failing on this one, but for what looks like reasons unrelated to this PR. Would you mind rebasing this onto the latest? Thanks.

[vik748]

@clalancette rebased, PTAL.

[tfoote]

Is there a planned path forward towards releasing this to enable ros package maintainers to use this in tests for released packages. To that end it would probably make more sense to release this as a ROS package rather than use it as a pip dependency.

[vik748]

@felixdivo can you comment on the plans with this project.

[felixdivo]

Thanks for pinging @vik748 :)

Currently, there is no such plan. But I wonder why a pip package would prevent its use in that case. I'm not too deep into the release and dependency management either. I'd be fond of keeping this pip-only since it simplifies the release management on my side, and pip needs to be available anyway.

[clalancette]

Currently, there is no such plan. But I wonder why a pip package would prevent its use in that case.

Because we essentially manage a distribution, all packages within that distribution can only depend on other binary packages. So all packages released on the buildfarm have to have their dependencies satisfied from either the underlying OS, or from another package in ROS.

It is certainly possible to make ROS packages that depend on pip keys; it is why rosdep has that capability. But in that case, the package will always have to be built from source and can never be released onto the ROS buildfarm.

[Timple]

and pip needs to be available anyway.

Why is this?

[felixdivo]

Okay, now I understand.

I like pip because one can easily create releases from an automated CI job. It is indeed not strictly necessary.

It seems like releasing to ROS-specific distributions is a bit more work. If that is the case, I'm not planning to do that myself, yet welcome others who would like to do it.

[quarkytale]

@vik748 need confirmation, you're hoping to move forward with this PR as is and understand the limitations?

[vik748]

Can someone point out to some instructions for adding a python package to the ros distribution. If not too onerous, I can volunteer to add and maintain that aspect.

[audrow]

@vik748, I think this is what you're looking for: https://github.com/ros/rosdistro/blob/master/CONTRIBUTING.md#python-rules

[vik748]

@audrow the link you provided is about contributing rosdep keys for pip projects. I was more looking into what it would take to make ros2-easy-test a first class ros package. See @tfoote and @clalancette comments above.

If you look at the https://github.com/felixdivo/ros2-easy-test, the package is not laid out like a typical ros package. I am guessing we'd need to make it look like a standard ros package with a manifest and a setup.cfg etc. @felixdivo would you be open to reorganization like that?

[felixdivo]

Yeah, okay. I'll do it, though it might take a few days.

It's not very hard, though it is annoying that we still need to use setup.py (https://github.com/colcon/colcon-core/issues/208) and to add all that unhelpful boilerplate. I don't want to be mad. I know ROS2 has a lot of design constraints, and steering a large project is challenging. Just trying to explain why I was very happy not to require it until now.

I'll post here once I'm done. :) Sorry for the slow iterations.

[github-actions[bot]]

This PR hasn't been activity in 14 days. If you are still are interested in getting it merged please provide an update. Otherwise it will likely be closed by a rosdistro maintainer following our contributing policy. It's been labeled "stale" for visibility to the maintainers. If this label isn't appropriate, you can ask a maintainer to remove the label and add the 'persistent' label.

[felixdivo]

@vik748 Could you have a look at https://github.com/felixdivo/ros2-easy-test/pull/33 and verify that this is what you need?

[vik748]

@felixdivo thanks for pushing this forward, I think it gets us in the right direction. Switching over all the dependencies to apt via the package.xml file per @Timple should do the trick. From my understanding the next step would be https://docs.ros.org/en/foxy/How-To-Guides/Releasing/Releasing-a-Package.html

[clalancette]

Given the last few comments here, I think this is going to go in a different direction. Because of that, I'm going to close this out. If that is not correct, please feel free to reopen.