Why are planning wrappers for external planners in prpy?

[psigen]

Consider the case of or_parabolicsmoother. We have the HauserParabolicSmoother class which lives in prpy, but depends on or_parabolicsmoother. Note that since we maintain both packages, we have the ability to put the prpy python binding in either one.

It seems more useful to keep the prpy binding with the external package (like or_trajopt) rather than split (like or_parabolicsmoother):

1. The API for the prpy binding is highly dependent on the external package. For example, every XML PlanningParameter in or_parabolicsmoother has to be carefully matched in the prpy Planner wrapper. Mismatches cause hard-to-diagnose reverts to default parameters. This means that prpy experiences version churn if any wrapped planner changes API.
2. Adding an or_parabolicsmoother.prpy module is basically free. If someone does not use a prpy binding included with or_parabolicsmoother, they incur no performance penalty or additional runtime dependencies. It also does not really inflate the size of the package itself. This is the same logic by which we include package.xml and xxxxConfig.cmake files in our third-party library repositories.
3. Unit tests can live with their planners. Since bugs in the planners can show up as unit test failures in prpy wrappers, it makes some sense that these unit tests should live with the planner implementation. The same test_depend mechanism that we use in prpy to include planners can instead be used to include prpy in planner tests.

Notes:

• Pure python planners and wrappers for third-party libraries can sensibly live in prpy.
• This has nothing to do with the ExternalProject build used in or_trajopt, that is an unrelated discussion.

[mkoval]

I agree with this as long as, like you say, wrappers for third-party libraries live in prpy. My only concern is test re-use. We currently use mixins to run the same tests across multiple planners that implement the same planning methods. We would have to move these mixins to a module that the planner package could implement.

I'd be happy to merge the pull request if you (or someone else) does the legwork. I don't have the time or interest in doing so myself.