Remove the EntitySource API and replace it with the VariableSource API

[awgreene]

At a high level, the Deppy Library checks if a set of constraints can be satisfied by a set of entities. Today, the Deppy Library expects users to implement the EntitySource interface to provide the entities that Deppy considers. There are a number of shortcomings with the existing interface that justify moving to using the VariableSource interface.

1. This API doesn't provide value: Deppy should not care if a user has given it an EntitySource, it should only rely on a set of Variables being provided, which are retrievable through the existing VariableSource interface
2. Needless conversion:: When Deppy is given a EntitySource, it is converted into Entities, which are further converted into variables for resolution. After resolution, we again convert the variables to entities to get the final list of output. The flow looks like: Input -> Entities -> Variables -> Solver -> Solution set (variables) -> Entities.

Moving away from EntitySources / entities will yield the following benefits:

• Simplification of the codebase.
• The EntitySource interface is strongly tied to the bundle concept introduced by OLM. Moving away from EntitySources/Entites would allow us to support other formats.

Open Questions:

• [spike] Do we need separate variable sources for each constraint? (eg). How would OLM specific constraints look like?

Follow up:

• Currently we have BundleEntities in operator controller, these need to be converted in variable sources and directly fed to resolver. The GetVariables method would take in the BMD and packages, construct a valid deppy identifier and add it to the resolver here
• Catalogd should also be updated to use VariableSources.

Related PRs:

• [revise] Remove Entity and EntitySource #95

Demo Script:

• Is there a need for a demo script?

[awgreene]

Tagging @perdasilva and @varshaprasad96 for review on this one.

[varshaprasad96]

One change:

Catalogd should also be updated to use VariableSources.

Catalogd does not deal with deppy directly. Its only the operator controller that fetches in contents from v1 catalog and converts them into deppy consumable format. As such Catalogd project/repository shouldn't require any change (afaik).

[github-actions]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.