Thoth’s resolver¶

As Python is a dynamic programming language, the actual resolution of Python software stacks might take some time (you’ve probably encountered this already). One of the reasons behind it is the fact that all packages need to be downloaded and installed to verify version range satisfaction during the installation. This is also one of the reasons Thoth builds its knowledge base - Thoth pre-computes dependencies in the Python ecosystem so that resolving can be done offline without interacting with the outside world.

Thoth’s resolver models resolution process as a Markov Decision Process - see introduction section for more info.

Dependencies are are resolved based on pre-computed dependency information stored in the Thoth’s knowledge base. This information is aggregated by Thoth’s solvers that are run for different software environments. An example can be a solver for Fedora:33 running Python3.9 or UBI:8 running Python3.8. These software environments can be then used as base software environments for running Python applications. These container images are also suitable as a base for running Python applications - see s2i base images provided by Thoth that are analyzed by Thoth itself and thus can provide recommendations considering the base image used.

Thoth’s resolver has two main purposes:

• resolve software stacks for Dependency Monkey runs and verify generated software stacks on Amun

• resolve software stacks for recommendations

To instantiate a resolver, one can use two main functions:

• Resolver.get_adviser_instance - a resolver that produces software stacks for recommendations

• Resolver.get_dependency_monkey_instance - a resolver that produces software stacks for Dependency Monkey

To resolve raw pipeline products, one can use Resolver.resolve_products method that yields raw products during a pipeline run. Another method, Resolver.resolve creates a complete report of an adviser run together with some additional pipeline run information. See pipeline section for code examples.

Resolver instance transparently runs stack resolution pipeline to produce scored software stacks.

During the whole run, resolver keeps context that is updated during runs and is accessible in pipeline units as well as passed to predictor’s run method to guide resolver in next states to be resolve.