Inconsistent repository installation behavior

[mitchnegus]

In tracking down the issue of doubly-referenced MCs, I realized that the behavior of the repositories.json file seemed inconsistent and a bit confusing (at least to me). We often have several model component repositories, but only those which are installed via firewheel repository install ... are included in the JSON database.

Would we consider changing the behavior of the RepositoryDb object to write all of the MCs to the JSON? And if so, maybe we could include information about the type of install in the database? I think this would make debugging the MC installation a lot easier...

I'm thinking the new database file could look something like:

[
  {
    "path": "/opt/firewheel/model_components/firewheel_repo_linux/src/firewheel_repo_linux",
    "install_method": "entry_point"
  },
  {
    "path": "/opt/firewheel/model_components_packages/firewheel_repo_dns/src/firewheel_repo_dns",
    "install_method": "entry_point"
  },
  {
    "path": "/opt/firewheel/model_components_packages/firewheel_repo_vyos/src/firewheel_repo_vyos",
    "install_method": "entry_point"
  },
  {
    "path": "/opt/firewheel/model_components_packages/firewheel_repo_base/src/firewheel_repo_base",
    "install_method": "entry_point"
  },
  {
    "path": "/opt/firewheel/model_components",
    "install_method": "direct"
  }
]

I can't find any documentation for the structure of the repositories.json file, so I don't think this is likely to affect the public API there.

If we do this, there are some other changes we might consider making to make the RepositoryDb object easier to use, and which would solve some of the little problems that pop up by changing the database structure. Specifically, this might be shifting the add_repository/delete_repository methods to take a path directly rather than a single-element dictionary {"path": <path>} like they do right now. Those would represent breaking changes, but it looks like we use each of those methods only once in the respective repository install/uninstall helpers.

[mitchnegus]

One suggestion for a solution is a wrapper around RepositoryDb methods that will:

1. Read the repositories.json file and create an attribute on the instance storing the current list of repos
2. Update the list of repos using the current state of entry point (pip installed) repos
3. Execute the action (add/delete/list) via the wrapped function
4. Write the updated set of repositories to the database

This would allow us to keep track of both the current set of directly installed repos and the entry point repos, such that the repositories.json file could reflect all of the MC repositories as one might expect.

(Making it easier to distinguish directly installed repos and entry point repos is part of the motivation for including the "install_method" key in the database schema I suggested above.)