Should we combine the grype and grype-db projects?

[wagoodman]

This has come up a couple of times in ad-hoc conversations so I wanted to try and get this in a ticket for more feedback. Today we have a project for grype (the application that matches packages and vulnerabilities) and grype-db (the application that builds the DB of vulnerabilities that grype uses).

We could consider combining these projects (where the grype-db codebase is merged into the grype repo). There are at least a couple ways this can go:

• Add another entrypoint (build two binaries): ./cmd/grype (today's) and ./cmd/grype-db
• Update the grype application with more subcommands: grype db build ...

It might mean that the workflow that uses grype / grype-db to build OSS databases nightly remains where it is or is also migrated... this would be TBD.

To be clear: this is purely speculative. At the current time there is no plan to make this change (as it is a lot of work), but again, since it's been asked a couple times I wanted to see if there was anyone out there with strong opinions about this and gather as much feedback as possible (👍 or 👎 this for a vote and optionally comment).

[willmurphyscode]

What are the advantages of combining them? When the question of combining them comes up, why does it come up?

[wagoodman]

Today the DB definitions live in grype. But it's grype DB that needs these for all schema versions. One conclusion is to move DB definitions into grype-db, however, DB concerns like namespace are tightly coupled to the definition of a grype package... so if we move these definitions we end up with a go module cycle, which is technically allowed, but highly discouraged.

We also have the problem of when making specific updates exactly what needs to be merged and released first before being able to continue. This is especially true with new DB schemas. Merging these repos does not eliminate the issue, but does alleviate it some: it's one less repo to coordinate such changes.