Add a registry for SCMTools.

Review Request #12333 — Created June 3, 2022 and submitted — Latest diff uploaded

Review Board

The way that SCMTools are kept track of is particularly old. From the
very earliest days of Review Board, we knew that we wanted to support
multiple different SCMs, and we had done this by creating a Tool model
which had a name and the module path of a class to instantiate. This was
populated via database fixtures, and Repository then had a relation to
the tool.

As we improved things and made everything extensible, we moved away from
fixtures and over to entry points, but this still had two major

  1. If there's a VersionConflict in the install, no entry points will
  2. There was still a manual step that had to happen to load the tool
    types from the entry points and populate the Tool table.
    Occasionally, usually due to problem #1, people would end up with an
    install that didn't have any Tool models, and we'd have to direct
    them to manually run the registerscmtools command.

This change is the first major step towards modernizing this entire part
of the system. This adds a new registry for storing the SCMTool classes.
By default, this is populated from three places. First, we load the
built-in SCMTools (whether or not entry points can load). Second, we
load anything present in entry points. Finally, we'll go through the
existing Tool table, and load anything else from there (while printing a
warning that said table is going away, and anything there will need to
be changed to use entry points or the register() method directly.

  • Checked that the registry was properly populated from built-ins and
    entry points.
  • Created a fake item in the tool table and populated the registry. Saw
    that it was added to the registry and the appropriate warning was
  • Removed an item from the Tool table. Re-populated the registry and saw
    that the Tool instance was properly created.
  • Ran unit tests.