global incremental ID creates issues for consumers

[alfredodeza]

What happened: The syft/pkg/catalog.go file has a global (unexported) variable that increments whenever a new package is added to the catalog. This creates a hard constraint of not being able to control the IDs and forces consumers to use the catalog one at the time.

This particular problem was evident when 2 tests where trying to create a pkg catalog from syft. When the two tests ran, one would fail. These tests were adding 3 packages each, and they both were relying on the fact that the IDs would be 0, 1, and 2. When both added the tests, the IDs for the second test would be 3, 4 and 5.

What you expected to happen: Not have a global auto-incrementing variable that is unexported, and possibly allow consumers to control it.

How to reproduce it (as minimally and precisely as possible): Create two functions that add to a pkg.catalog

Anything else we need to know?:

Environment:

• syft version (use syft version -v):
• OS (e.g: cat /etc/os-release or similar):

[wagoodman]

Agreed on the global ID. Ultimately IDs should not have any expected behavior or pattern. We should probably change the ID to be a UUID to remove the statefulness of the existing IDs --allowing for consumer control would be a simple fix, but is not advised.

If the tests are within the the same package as the catalog, then setting them manually would be one approach. However, if tests reside outside of the package it would be difficult to redact these fields during comparison (hence, the problem you described).

Currently the ID field is used to distinguish when you have two package objects that are from the same catalog entry --this doesn't discount the possibility of having duplicate packages in the catalog (which is what #32 is meant to solve).

I think we should take time to solve the overall problem of the ID: what do we need it for? Can we solve the same problem without needing an ID field on the package which is assigned by the catalog?