There are multiple workflow management service specific plugins for ctrl_bps. Currently three of them live inside the ctrl_bps package: HTCondor, (out of date) Pegasus, and PanDA. Keeping the plugin code tucked away in a subdir is no longer working well:

• There are new PanDA specific executables (e.g., to reset authentication because there isn't one as part of the PanDA client install). The various click files had to be done differently than normal to separate the bps and PanDA files.
• There's a PanDA specific bps yaml file that needs to be included by users that was put in a high-level generic directory to be easy to find. 
• scons was failing because a plugin file included an iDDS module which required a config file. This required adding a config file + changing the tests/SConstruct to set the environment. This is without any actual plugin unit test being written yet. (This config requirement will be fixed in the next iDDS version.)

While there is nothing currently that is a blocker, the packages will be cleaner if the plugins are kept separate from the generic core bps code. It would also be easier to demote a plugin back to lsst-dm if not currently actively supported and/or moved to legacy.

• Each plugin would get its own package, ctrl_bps_<wms>, that would depend upon ctrl_bps.
  • HTCondor and PanDA are the packages currently actively maintained.  If no one is responsible to update and maintain Pegasus plugin it should be moved to lsst-dm.
• Similar to lsst_obs there would be an lsst_bps_plugins meta package that would be included by lsst_distrib and contain the plugins to be included by lsst_distrib. 
• When first splitting up the packages, there may be some reorganization of files (e.g., moving up files that were way down under a plugin directory up higher).  This should be a one time effort.
• Can move and maintain plugin-specific documentation into their own package (some docs live in google docs)  

One downside is that if making changes to ctrl_bps, multiple plugin packages could also need to be changed.  However, that's just a change in code location.   We currently can't manually test changes to multiple plugins from one location even if in one package and there are different people typically making changes to the plugins via different tickets than the core code changes.

User impact:  

• There is a wmsServiceClass config value that is normally set by default configs (e.g., lsst.ctrl.bps.wms.htcondor.htcondor_service.HTCondorService)  So this change should happen behind the scenes for most users.
• For other subcommands than submit (like bps cancel) which do not take a config file, there's an environment variable that would need to be changed.  But most plugins at the moment only support the submit subcommand.  
• If we want the wms specific config values from their package to also be set by default for users, there would need to be some ctrl_bps changes (which I would prefer to be a separate ticket). 

Note:  We'll want to do the isort/black changes to ctrl_bps before breaking it up.