Scenario

Given a project which has dependencies but no lockfile, the package manager
is unable to determine any transitive dependencies. It always creates an analyzer error
to indicate that the result is incomplete, and reports only direct dependencies.

Problem

The implementation tolerates the lockfile to be absent. This tolerance seems to introduce quite
a bit of complexity into the mapping logic from ORT's model to Gleam's model. For example,
the inheritance hierarchy of the dependeny classes, along with a bit of code redundancy.
This seems to be a high price for a use case which does not work anyway (transitive deps are missing).

Proposal

Change the package manager implementation, so that it fails reporting any dependencies at all,
instead of only the direct ones, if: project has dependencies AND lockfile is absent.

..and apply the unlocked code simplifications. That is, the code can assume, for each dependency an
entry in GleamManifest.packages to be present.

Note: My current understanding is, that the dependency tree construction can then only be based on GleamManifest.packages, plus a couple of fetches via the HexApiClient for the metadata.

Future

Question: In case of an absent lockfile, could we generate it on-the-fly?