Add VS Code Setup Instructions #338
Conversation
There was a problem hiding this comment.
Just a couple typos that I noticed while going through this. Apart from that, this looks very well done!
@esteve a policy question - do we want to take a stance as to which IDE we recommend people use when working with rclrs? While I do enjoy VSCode for development, I could also see us wanting to remain a bit neutral in that regard. Not saying that this contribution can't be added, mind you, I'm just wondering if we want to say that we recommend people use VSCode, is all. I'll defer to your judgement on that.
Regardless, thank you VERY much for this @Carter12s! I think this will be very useful for people that want to use VSCode with ROS 2 Rust!
Fair point, happy to strip that language from MR. In my opinion it is extremely important to provide a "Batteries Included" path for people getting started with a new complex system (like ROS2). I'm imagining the use case of someone new to both ROS and Rust thinking this could be a good place to start with both (probably a lot of grad students in this position as we speak). I would say anyone who has enough experience to have an opinion against using VS Code probably doesn't need these instructions, and probably won't be offended by the suggestion. But, either way understand the neutral stance if desired. |
|
@jhdcs Ready for a second look, all suggestions addressed and caught a couple other missing words. |
| # Default source the ros environment, this correctly sets up the environment | ||
| # For vscode and rust-analyzer to work inside the docker image | ||
| RUN echo "source /opt/ros/$ROS_DISTRO/setup.bash" >> /root/.bashrc |
There was a problem hiding this comment.
I personally disagree with the approach of adding source to the user's bashrc.
Apart from being (imho) a bad habit, it is convenient for "most" cases but can cause footguns in others. For example let's say a user wanted to do any change on the ROS 2 source code that requires them to compile it from source.
If they did a ROS 2 source build and naively sourced the install/setup.bash they would end up with two overlays. I believe multiple overlays can create a fair bit of trouble if ABI / API compatibility is not respected, as documented in this discussion colcon/colcon-core#465 and in the extensive warnings printed at compile time.
Also, there is a minor footgun for the source build case in which, since a ROS installation is automatically sourced, if users forget the source install/setup.bash command, their commands will "just work" which might not be what they expect.
There was a problem hiding this comment.
No that is a super fair point, and I felt dirty doing this.
Do you know of a workaround / alternative? Party of why I wrote these instructions was because of how hard I found it to get the basic Rust tooling that I'm used to having working with this project.
VS Code supports loading environment variables in a few different ways, but I don't think there is any good way to "export" the right variable definitions out of a terminal instance inside the container and then load them into VS Code. Even if you did this it would be really brittle (maybe a VS Code plugin could update automatically).
I can find stack-overflow questions looking for a way of doing this, but no answers.
The crux of the issue is that rust-analyzer and programs launched via its launch configurations, don't provide a way to say "run this bash command ahead of time"...
I can keep digging... But this shouldn't be this hard.
There was a problem hiding this comment.
So I went on a rabbit hole to try to find other ROS projects that have "solved this problem".
I found Nav2 which is doing a fancier (and probably better) version of sourcing in the .bashrc: https://github.com/ros-planning/navigation2/blob/main/Dockerfile#L153
I'm don't 100% understand what they are doing with their UNDERLAY_WS, but it seems like the better thing to do would be to invoke colcon build in the Dockerfile to get setup.bash to generate, and then source that instead of directly sourcing iron/setup.bash
Is that a good enough solution?
I'll be frank I'm coming from ROS1 and haven't touched ROS2 workspaces yet, so learning while doing here.
There was a problem hiding this comment.
In my opinion, it's fine to source ros setup.bash in the docker's .bashrc.
To my understanding, this is a docker setup, not a local host system setup. The user of the docker has less possibility to rebuild ROS2 from source.
|
Hello, there is a MR #435 that may be a better way to help people to use docker and devcontainers, if I can have your feedback, maybe we can consider to update the new MR with useful info from this MR and proceed closing this one. Thank you!! |
Hopefully this is useful.