Drake: Installed (and binary release) drake-visualizer lacks useful default plugins

[jwnimmer-tri]

When we run bazel-bin/tools/drake_visualizer, useful plugins like show_image are on by default. When a user is running from an installed copy of Drake, they are off by default (and not even in the menus as an option, IIRC). We shouldn't have to ask a user "_Which_ visualizer copy were you running" -- they should all just work the same. Call to action: bake in the plugins to our installed drake-visualizer, as well.

\CC @EricCousineau-TRI @jamiesnape

[jwnimmer-tri]

We could upstream the code into director, or we could install the director binary as bin/drake-visualizer.real and install our own bin/drake-visualizer tiny shim, or ...

[jamiesnape]

So in effect #9653 only fixed half the problem of #9608?

[EricCousineau-TRI]

Yup! The only pain point that I was aware of (but I see I did not explicitly state) was Drake + Anzu workflows, which was Bazel-centric.

This also partially relates the discussion for #7050 - e.g. doing an install_test on director and importing our scripts. (Well, marginally relates it, in that drake_visualizer --help won't actually test the script imports...)

The scripts have been relatively stable, so I'd be fine with upstreaming them; however, I think just having them installed would be kinda easier. Just need to install to drake instead of pydrake (and ensure __init__.py modules are added), and then things should work just fine.

[jwnimmer-tri]

Having an install-based workflow (instead of upstreaming the plugins) makes it easy-by-way-of-example for us to add and tweak more default plugins as we invent them, without having to launder them through pre-compiled Director releases.

[jwnimmer-tri]

Here's the best workaround I've found so far.

This example uses the Drake v0.17.0 binary release image for Ubuntu. The CMake install should produce an identical result.

We need to use a source tree for the plugins, because the install tree does not have the plugins available anywhere. But the python path doesn't work easily mixing the source and install trees, so we need to comment out the scoped_singleton_func stuff.

(1) Download and untar the image into ~/Downloads/v0.17.0.

(2) Clone Drake git into ~/jwnimmer-tri/drake.

(3) Patch each plugin like so:

--- a/tools/workspace/drake_visualizer/plugin/show_time.py
+++ b/tools/workspace/drake_visualizer/plugin/show_time.py
@@ -5,7 +5,7 @@ from director import lcmUtils
 from director import applogic
 from director.visualization import updateText

-from drake.tools.workspace.drake_visualizer.plugin import scoped_singleton_func
+# from drake.tools.workspace.drake_visualizer.plugin import scoped_singleton_func


 class TimeVisualizer(object):
@@ -78,7 +78,7 @@ class TimeVisualizer(object):
         updateText(my_text, 'text')


-@scoped_singleton_func
+# @scoped_singleton_func
 def init_visualizer():
     time_viz = TimeVisualizer()
     # Adds to the "Tools" menu.

(4) Run ~/Downloads/v0.17.0/drake/bin/drake-visualizer --script ~/jwnimmer-tri/drake/tools/workspace/drake_visualizer/plugin/show_time.py

Bottom line, we really need to fix the install.

[mjm522]

Using the info given by @jwnimmer-tri , I copied and modified the plugin folder to the bin and it works. The repo is here. This is a quick fix for anyone using the binary to get all the plugins activated.

You need to run drake-binary-with-plugins/bin/drakeVisualizerPluginEnabled

[jamiesnape]

Does not seem like a difficult fix if we relocate and install scoped_singleton_func, etc. Can we refactor all the plugins and utility files into a single module that we install? No reason to have to use anything Bazel-specific as far as I can tell. Adding a wrapper to ensure the plugins are loaded is trivial enough.

[EricCousineau-TRI]

Taking 30min to work on this now.

I disprefer changing the plugins at this point, and will try just futzing with the install tree first with a simple shim. Failing that, will take either @jamiesnape's suggestion, or the route that @jwnimmer-tri suggested and @mjm522 reproduced.

[jamiesnape]

It's not a huge change, just a different module name and PYTHONPATH ultimately (the shim would make me longer to write, even).

[EricCousineau-TRI]

Took longer, but I think I also ended up solving some form of #7050.

WIP Branch: https://github.com/RobotLocomotion/drake/compare/master...EricCousineau-TRI:issue-10486-wip