search

ros2 / ros2_documentation

ROS 2 docs repository
https://docs.ros.org/en/rolling
Creative Commons Attribution 4.0 International
531 stars 1.05k forks source link

Switch from ros2.repos to rosinstall_generator for source installation instructions #1470

Open tfoote opened 3 years ago

tfoote commented 3 years ago

We've slowly been preparing for phasing out the ros2.repos file in favor of using the rosinstall_generator like we do for ROS 1. e.g. melodic

This will improve our documentation to allow users more granularity and control of what they install. It's been directly requested and experienced developers were able to inform them how to use our more powerful tools that exist and work well, but are undocumented.

There will be some necessary documentation of what variants are expected to work on each platform. But not giving people the tools seems to have more downsides.

As we're late in the galactic release cycle I'd like to suggest that we officially plan to switch rolling documentation over and plan for H-Turtle to inherit the newer more dynamic approach.

ros-discourse commented 3 years ago

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/core-base-and-desktop-releases/20267/4

clalancette commented 3 years ago

Before we make changes here, I think it is worthwhile to define the target audience of the build-from-source instructions.

If the target audience is "people who can't use the binary packages, but just want to use ROS 2", then I agree that switching to rosinstall_generator is better. It will get them something closer to what the Debian packages are providing.

But if the target audience is "people who want to work on the core of ROS 2", the situation is murkier to me. The current instructions more-or-less follow how the CI jobs work (at least on Linux and macOS; Windows is now totally different). That means that if a user checks things out in that way, and runs the appropriate tests, there is a good chance that things will work on the CI job when they open a PR. If we switch to rosinstall_generator for the instructions, then that is further away from what CI does.

There is a way to resolve this discrepancy, which is to make the CI jobs use rosinstall_generator. That is one of the long-term goals I would like to get done for ROS 2, so maybe it is worthwhile addressing that first.

MAVProxyUser commented 1 year ago

"The current instructions more-or-less follow how the CI jobs work" the current instructions are disjunct, broken across various OS versions Debian, Ubuntu, Raspbian, RaspiOS, etc, and ROS versions.

"the target audience" should be "anyone that seeks to make ROS as a project usable" from a basic source code tree of the various components and their dependencies.

CI, and end users are not at all the same thing. CI very often involves nasty hacks to force things to build in ONE very specific environment. It flat out isn't scalable in the context of offering instructions to end users. What you all do in CI is your own business.

rosdep is a nightmare, and flat out does not work in many situations.

My first experience with a source code build was because of the landscape left by Nvidia Jetson & JetPack versions. Installing the proper ROS version on a Jetson device is really difficult if you have specific version needs. Half the instructions say use colcon, something else says use catkin, you fall into traps of needing to know specific branch names if you dare try to checkout via git without vcs and a full repo export.

The Xiaomi Cyberdog for example uses a Jetson at its core, but they wanted ROS2, so had to do a custom compile with very specific version and certain packages omitted.

https://github.com/MiRoboticsLab/cyberdog_ros2/wiki/从源码安装ROS-2-%7C-Building-ROS-2-from-source

I was very pleased when I saw rosinstall_generator dump out a vcs script for me to import.