# Buildsheet autogenerated by ravenadm tool -- Do not edit. NAMEBASE= python-resolvelib VERSION= 1.1.0 KEYWORDS= python VARIANTS= v12 v13 SDESC[v12]= Abstract dependencies resolver library (3.12) SDESC[v13]= Abstract dependencies resolver library (3.13) HOMEPAGE= https://github.com/sarugaku/resolvelib CONTACT= Python_Automaton[python@ironwolf.systems] DOWNLOAD_GROUPS= main SITES[main]= PYPIWHL/cb/1b/ddbb64024a94228e10e65c98c9f28bb235d6947998238bbfe665a044f3d8 DISTFILE[1]= resolvelib-1.1.0-py2.py3-none-any.whl:main DIST_SUBDIR= python-src DF_INDEX= 1 SPKGS[v12]= single SPKGS[v13]= single OPTIONS_AVAILABLE= PY312 PY313 OPTIONS_STANDARD= none VOPTS[v12]= PY312=ON PY313=OFF VOPTS[v13]= PY312=OFF PY313=ON DISTNAME= resolvelib-1.1.0.dist-info GENERATED= yes [PY312].USES_ON= python:v12,wheel [PY313].USES_ON= python:v13,wheel [FILE:2581:descriptions/desc.single] ========== ResolveLib ========== ResolveLib at the highest level provides a Resolver class that includes dependency resolution logic. You give it some things, and a little information on how it should interact with them, and it will spit out a resolution result. Intended Usage ============== :: import resolvelib # Things I want to resolve. requirements = [...] # Implement logic so the resolver understands the requirement format. class MyProvider: ... provider = MyProvider() reporter = resolvelib.BaseReporter() # Create the (reusable) resolver. resolver = resolvelib.Resolver(provider, reporter) # Kick off the resolution process, and get the final result. result = resolver.resolve(requirements) The provider interface is specified in ``resolvelib.providers``. You don't need to inherit anything, however, only need to implement the right methods. Terminology =========== The intention of this section is to unify the terms we use when talking about this code base, and packaging in general, to avoid confusion. Class and variable names in the code base should try to stick to terms defined here. Things passed into ``Resolver.resolve()`` and provided by the provider are all considered opaque. They don't need to adhere to this set of terminologies. Nothing can go wrong as long as the provider implementers can keep their heads straight. Package ------- A thing that can be installed. A Package can have one or more versions available for installation. Version ------- A string, usually in a number form, describing a snapshot of a Package. This number should increase when a Package posts a new snapshot, i.e a higher number means a more up-to-date snapshot. Specifier --------- A collection of one or more Versions. This could be a wildcard, indicating that any Version is acceptable. Candidate --------- A combination of a Package and a Version, i.e. a "concrete requirement". Python people sometimes call this a "locked" or "pinned" dependency. Both of "requirement" and "dependency", however, SHOULD NOT be used when describing a Candidate, to avoid confusion. Some resolver architectures refer this as a "specification", but it is not used here to avoid confusion with a *Specifier*. Requirement ----------- An intention to acquire a needed package, i.e. an "abstract requirement". A "dependency", if not clarified otherwise, also refers to this concept. A Requirement should specify two things: a Package, and a Specifier. Contributing ============ Please see [developer documentation]. [FILE:127:distinfo] f80de38ae744bcf4e918e27a681a5c6cb63a08d9a926c0989c0730bcdd089049 18053 python-src/resolvelib-1.1.0-py2.py3-none-any.whl