Add hints about failing import on Linux #875
Conversation
There was a problem hiding this comment.
Capturing this problem in the troubleshooting guide I think makes sense, but I think getting a better understanding of what the root problem is and what the correct fix is is important to explain. Rather than adding an addemdum to a section that if you see a similar error in another circumstance run this command.
| @@ -304,6 +304,14 @@ If you are still having issues, you can use the `Dependencies <https://github.co | |||
| Use the tool to load the corresponding ``.pyd`` file, and it should report unavailable ``DLL`` modules. | |||
| Be sure that the current workspace is sourced before you execute the tool, otherwise there will be unresolved ROS DLL files. | |||
| Use this information to install additional dependencies or adjust your path as necessary. | |||
| ` | |||
| If you see an error similar to this on Linux, rebuilding the `install` directory of your workspace (eg. ``~/dev_ws``) might help: | |||
There was a problem hiding this comment.
This is a very specific proscription for a very specific problem that I think should be more general. (To start with the problem isn't specific to linux) This is coming from a problem where the import is failing because the dependencies have changed. rm -rf is kind of a nuclear option.
I think it would be better to mention that you may get this problem if the dependencies of your workspace have changed and that in that case you should force a rebuild. Also note that depending on how much is cached in your build directory it's quite possible that the cached elements in the build directory will propagate if the dependency is not being tracked.
This also is in the Windows Troubleshooting section which isn't necessarily the most appropriate for a generic problem like this.
There was a problem hiding this comment.
Fair enough. What is the canonical way to rebuild a workspace? AFAIK, there is nothing like a colcon clean, that clears both the build and install directories.
There was a problem hiding this comment.
Thanks for reducing this. One small fixup left.
To answer your question: If you want to fully clean a workspace rm -rf build install is a pretty quick way to do that that doesn't really need a name/alias. Depending on why you're clearing things up you might not want to delete the build artifacts. if your build rules are written correctly there's very few reasons to truely delete the workspaces.
Encouraging people to just delete their workspace if something isn't quite working will lead to more rebuilds of unnecessary components as well as people paying less attention to making sure that their rules are right and just requiring full rebuilds.
There's definitely more space for filling this out and discussing it but I'd suggest maybe extending the developer documentation for how to manage your workspace.
Signed-off-by: Tully Foote <[email protected]>
See ros2/ros2cli#567