| Name | resolvelib JSON |
| Version |
1.1.0
JSON |
| download |
| home_page | None |
| Summary | Resolve abstract dependencies into concrete ones |
| upload_time | 2024-10-31 01:26:09 |
| maintainer | None |
| docs_url | None |
| author | None |
| requires_python | >=3.7 |
| license | ISC License |
| keywords |
dependency
resolution
|
| VCS |
 |
| bugtrack_url |
|
| requirements |
No requirements were recorded.
|
| Travis-CI |
No Travis.
|
| coveralls test coverage |
No coveralls.
|
==========
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 <./DEVELOPMENT.rst>`__.
Raw data
{
"_id": null,
"home_page": null,
"name": "resolvelib",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.7",
"maintainer_email": null,
"keywords": "dependency, resolution",
"author": null,
"author_email": "Tzu-ping Chung <uranusjr@gmail.com>",
"download_url": "https://files.pythonhosted.org/packages/79/e6/53dc936ddd11353967e5cb7361f537042914745fccfcaa3475505c9ac596/resolvelib-1.1.0.tar.gz",
"platform": null,
"description": "==========\nResolveLib\n==========\n\nResolveLib at the highest level provides a ``Resolver`` class that includes\ndependency resolution logic. You give it some things, and a little information\non how it should interact with them, and it will spit out a resolution result.\n\n\nIntended Usage\n==============\n\n::\n\n import resolvelib\n\n # Things I want to resolve.\n requirements = [...]\n\n # Implement logic so the resolver understands the requirement format.\n class MyProvider:\n ...\n\n provider = MyProvider()\n reporter = resolvelib.BaseReporter()\n\n # Create the (reusable) resolver.\n resolver = resolvelib.Resolver(provider, reporter)\n\n # Kick off the resolution process, and get the final result.\n result = resolver.resolve(requirements)\n\nThe provider interface is specified in ``resolvelib.providers``. You don't\nneed to inherit anything, however, only need to implement the right methods.\n\n\nTerminology\n===========\n\nThe intention of this section is to unify the terms we use when talking about\nthis code base, and packaging in general, to avoid confusion. Class and\nvariable names in the code base should try to stick to terms defined here.\n\nThings passed into ``Resolver.resolve()`` and provided by the provider are all\nconsidered opaque. They don't need to adhere to this set of terminologies.\nNothing can go wrong as long as the provider implementers can keep their heads\nstraight.\n\nPackage\n-------\n\nA thing that can be installed. A Package can have one or more versions\navailable for installation.\n\nVersion\n-------\n\nA string, usually in a number form, describing a snapshot of a Package. This\nnumber should increase when a Package posts a new snapshot,\ni.e a higher number means a more up-to-date snapshot.\n\nSpecifier\n---------\n\nA collection of one or more Versions. This could be a wildcard, indicating that\nany Version is acceptable.\n\nCandidate\n---------\n\nA combination of a Package and a Version, i.e. a \"concrete requirement\". Python\npeople sometimes call this a \"locked\" or \"pinned\" dependency. Both of\n\"requirement\" and \"dependency\", however, SHOULD NOT be used when describing a\nCandidate, to avoid confusion.\n\nSome resolver architectures refer this as a \"specification\", but it is not\nused here to avoid confusion with a *Specifier*.\n\nRequirement\n-----------\n\nAn intention to acquire a needed package, i.e. an \"abstract requirement\". A\n\"dependency\", if not clarified otherwise, also refers to this concept.\n\nA Requirement should specify two things: a Package, and a Specifier.\n\nContributing\n============\n\nPlease see `developer documentation <./DEVELOPMENT.rst>`__.\n",
"bugtrack_url": null,
"license": "ISC License",
"summary": "Resolve abstract dependencies into concrete ones",
"version": "1.1.0",
"project_urls": {
"Homepage": "https://github.com/sarugaku/resolvelib"
},
"split_keywords": [
"dependency",
" resolution"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "cb1bddbb64024a94228e10e65c98c9f28bb235d6947998238bbfe665a044f3d8",
"md5": "02b93bc77161055a255760cff8daca49",
"sha256": "f80de38ae744bcf4e918e27a681a5c6cb63a08d9a926c0989c0730bcdd089049"
},
"downloads": -1,
"filename": "resolvelib-1.1.0-py2.py3-none-any.whl",
"has_sig": false,
"md5_digest": "02b93bc77161055a255760cff8daca49",
"packagetype": "bdist_wheel",
"python_version": "py2.py3",
"requires_python": ">=3.7",
"size": 18053,
"upload_time": "2024-10-31T01:26:07",
"upload_time_iso_8601": "2024-10-31T01:26:07.383339Z",
"url": "https://files.pythonhosted.org/packages/cb/1b/ddbb64024a94228e10e65c98c9f28bb235d6947998238bbfe665a044f3d8/resolvelib-1.1.0-py2.py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "79e653dc936ddd11353967e5cb7361f537042914745fccfcaa3475505c9ac596",
"md5": "5584aa074883beb4271fb2842efef1ad",
"sha256": "b68591ef748f58c1e2a2ac28d0961b3586ae8b25f60b0ba9a5e4f3d87c1d6a79"
},
"downloads": -1,
"filename": "resolvelib-1.1.0.tar.gz",
"has_sig": false,
"md5_digest": "5584aa074883beb4271fb2842efef1ad",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.7",
"size": 22551,
"upload_time": "2024-10-31T01:26:09",
"upload_time_iso_8601": "2024-10-31T01:26:09.327524Z",
"url": "https://files.pythonhosted.org/packages/79/e6/53dc936ddd11353967e5cb7361f537042914745fccfcaa3475505c9ac596/resolvelib-1.1.0.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-10-31 01:26:09",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "sarugaku",
"github_project": "resolvelib",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"lcname": "resolvelib"
}
