Missing module __init__ in package containing messages and catkin_python_setup()
Closed this issue · 11 comments
Pretty sure this is a repeat of issue #10.
My package works fine in devel space, when I go to install it, I get this:
$ catkin_make install | grep __init__
Compiling /home/mikepurvis/husky_ws/devel/lib/python2.7/dist-packages/clearpath_base/__init__.py ...
Compiling /home/mikepurvis/husky_ws/devel/lib/python2.7/dist-packages/clearpath_base/msg/__init__.py ...
-- Installing: /home/mikepurvis/husky_ws/install/lib/python2.7/dist-packages/clearpath_base/msg/__init__.pyc
-- Installing: /home/mikepurvis/husky_ws/install/lib/python2.7/dist-packages/clearpath_base/msg/__init__.py
The __init__.py file in the package root get compiled, but it never gets installed.
On a hunch, I finally removed catkin_python_setup(), and then it does the right thing and installs the __init__.py file:
$ catkin_make install | grep __init__
Compiling /home/mikepurvis/husky_ws/devel/lib/python2.7/dist-packages/clearpath_base/__init__.py ...
Compiling /home/mikepurvis/husky_ws/devel/lib/python2.7/dist-packages/clearpath_base/msg/__init__.py ...
-- Installing: /home/mikepurvis/husky_ws/install/lib/python2.7/dist-packages/clearpath_base/__init__.pyc
-- Installing: /home/mikepurvis/husky_ws/install/lib/python2.7/dist-packages/clearpath_base/__init__.py
-- Installing: /home/mikepurvis/husky_ws/install/lib/python2.7/dist-packages/clearpath_base/msg/__init__.pyc
-- Installing: /home/mikepurvis/husky_ws/install/lib/python2.7/dist-packages/clearpath_base/msg/__init__.py
I know this is not an ideally-named package (or API design), but it's this way to maintain consistency with some historical decisions. The package source is here:
https://github.com/clearpathrobotics/clearpath_base
For now, I'm going to just work around this by manually installing the file, but it was a pretty nasty bug to figure out.
For interested parties, here's the workaround:
install(FILES ${CATKIN_DEVEL_PREFIX}/${CATKIN_PACKAGE_PYTHON_DESTINATION}/__init__.py
DESTINATION ${CATKIN_PACKAGE_PYTHON_DESTINATION})
The problem why this happens in your case is that the message generation happens for the package name clearpath_base but the Python package(s) being installed are actually named differently.
I am not sure if and how this can be fixed in genmsg/catkin. I will have to look into it a bit more.
[The "right" solution would probably be to only have a Python package which matches the package name and if multiple package names are necessary split the ROS package into multiple ones.]
Okay, cool. The main frustration is that it's such a subtle failure—might be something to try to warn the user about at build time, or even refuse to build.
I have fixed the issue in the affected packages (catkin, genmsg, dynamic_reconfigure).
As soon as these packages are released (next days) you should revert your workaround (clearpathrobotics/clearpath_base@e0b4510) and add a versioned dependency to ensure that you depend on the latest version of the packages.
Hi Dirk—sorry to trouble you. How do I declare a versioned dependency? I checked out the package.xml page, and didn't see any mention of it.
Alternatively, is there any harm in just leaving it in? I can always zap it in a few weeks when the coast is definitely clear.
It is defined in the REP:
I am not sure if the install rules will collide?
Since your package will rely on a specific minimum version of another package it should declare that. Nothing prevents a user from having an older version of e.g. catkin/genmsg installed but updated your package.
Hmm, okay. I believe I've made the correct changes in the following branch: https://github.com/clearpathrobotics/clearpath_base/compare/genmsg_workaround_removal
Once you've released catkin 0.5.74 and genmsg 0.4.23, then I'll merge that branch and cut a new release of clearpath_base.
The changes on the branch look good - I will comment as soon as the packages are released.
The packages have been released so you can go ahead and also release your packages.
Package is released and works great, thanks. I appreciate the hand-holding.