VXL Just plugin

I think it should be possible to write a pyvxl plugin

We've added pyvxl to enough projects now, that it's becoming a common pattern that we are copying to get VXL added: https://bitbucket.org/visionsystemsinc/volume_model/branches/compare/main%0D0497eab354ec40f93be30c6100a7087d163e3070#diff

1. Take the CMakefile and add that as part of the plugin.
   1. The project name would be something like pyvxl
   2. The volume model prefixes would be replaced with generic
2. compile would be in the plugin file
3. There would also need to be an internal plugin added too, for the internal just compile
4. The docker for compiling vxl in
5. The plugin would be responsible for the "build" volume
6. A way to export this for airgap (not fully deployed scenario)
7. Make sure easy to get compiled pyvxl for fully deployed scenario

Main project (manual?) steps would still include:

1. Added external/vxl, pyvxl, and pybind11 (can pybind11 be optional?)
2. Adding PYTHONPATH=${PYVXL_INSTALL_DIR_DOCKER}/lib/python3/site-packages to docker-compose.yml?
   • It might be possible to embed this in /usr/local/share/just/user_run_patch instead of docker-compose, but then that makes it more automatic and more hidden, trade-off

Unknown

1. How to pass install volume from plugin to project
   1. I image using the volume: name: in docker-compose, we could come up with a pattern that would include project and user name, and manually add it to the project's docker-compose too.

Start by comparing the linked volume_model CMakefile with the proposed pyvxl plugin structure. Review docker-compose.yml and /usr/local/share/just/user_run_patch for the PYTHONPATH and build-volume integration, then trace the internal plugin, Docker compilation, air-gapped export, and fully deployed workflow. Done requires a defined plugin interface, volume-passing approach, and resolution of whether pybind11 is optional.