Location to install a plugin managed by pluginlib

[lepalom]

As the definition of the package says: "pluginlib is a C++ library for loading and unloading plugins from within a ROS package". The implementation of that is that every plugin is build as a shared library.

In the case that ROS was installed in /usr to follow FHS instead that /opt/ros/$distro/lib, a ros installation with multiple packages providing plugins the /usr/lib/* (or /usr/lib/$arch/*) directories contain a bunch of "libraries" that are not public libraries for the system installed in the place of public libraries. This consideration could be applied to /opt/ros/$distro/lib.

So, the plugins created by this library should go so some directory inside the default library path (i.e. /opt/ros/$distro/lib/ros-plugins or /usr/lib/ros/plugins or /usr/lib/ros or /usr/lib/pluginlib or whatever you consider appropriate.

Some references could be found here:

http://www.tldp.org/HOWTO/HighQuality-Apps-HOWTO/plugin.html
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

I cannot evaluate the implications of that change (catkin, LD_LIBRARY_PATH, RUNPATH, etc), but it should be consider.

[wjwwood]

I'm about to do some work on pluginlib in preparation for using it in ROS 1 and ROS 2 at the same time, and I wanted to take the time to respond to this issue. Sorry no one has given feedback until now.

---

So, the plugins created by this library should go so some directory inside the default library path (i.e. /opt/ros/$distro/lib/ros-plugins or /usr/lib/ros/plugins or /usr/lib/ros or /usr/lib/pluginlib or whatever you consider appropriate.

I would be happy for pluginlib to support this case and maybe even recommend it, but I do not believe this is something pluginlib should enforce. It would be convenient for organizational purposes for people to put plugins for a particular application in a particular subfolder in lib, but it does not appear to be required.

http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

This reference states:

Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory.

But it doesn't say it must use a subdirectory or even that it should if it has plugins. So I don't see that as a mandate to do so for plugins.

http://www.tldp.org/HOWTO/HighQuality-Apps-HOWTO/plugin.html

This reference is more opinionated (based on recommendation, not part of a standard like FHS), but it states:

Well, and extension is nothing more that some files in a right format (DLLs that implements the API your Software defined), put in the right folders (directories your Software looks for extensions).

Which is a principle that pluginlib adheres to (in my opinion), in that a plugin for an application like rviz doesn't need to modify a global configuration file or rviz itself to be a plugin. It goes on to say:

The most important thing to consider in your plugin architecture is to not share files between plugins and your Software. You should provide an architecture where plugins will be able to fully install and uninstall themselves by simply putting and removing files in specific directories, documented in you Software.

Which reinforces the idea that no matter how you do it, just make plugins decoupled from the application's installation or configuration. Again, which I believe pluginlib does already. Finally, it gives a recommendation on where to put the files:

Good candidates are /usr/lib/myproduct/plugins as the plugins directory, and /etc/myproduct/plugins as the plugins configuration files directory.

So, from my perspective, this is a recommendation, not a requirement as well. (oddly, /usr/lib/myproduct/plugins seems to be at odds with what the FHS allows, a single subdirectory in lib)

---

@mikaelarguedas I believe pluginlib is already flexible enough to support arbitrary subdirectories with <install prefix>/lib (regardless of whether or not <install prefix> is /opt/ros/$distro or /usr), but I think we could add a test for this case too.

So I propose we close this (with a "wontfix" for the recommendation to enforce the subdirectory in lib) and open issues to either support or test (if already supported) subdirectories in lib for plugins and to update the recommendation for plugins to be installed in a subdirectory.