On 25/3/2020, at 05:37, Wes Turner <wes.turner@gmail.com> wrote:
On Tue, Mar 24, 2020 at 5:24 PM Tzu-ping Chung <uranusjr@gmail.com <mailto:uranusjr@gmail.com>> wrote: To expand a little on the topic, there are multiple abstraction layers required to make the new resolver useful as a separate package.
ResolveLib (mentioned in Paul’s message) is an dependency resolver implementation in abstract, entirely divorced of Python packaging. While it can be used by other tools, the implementer would need to provide the necessary parts to “teach” it how understand Python packages.
The ongoing pip resolver work is exactly that, to integrate ResolveLib into pip by wiring it onto pip’s internal representation of Python packages. This is unfortunately not really reusable for other tools, since pip’s current model on Python packages is too deeply entangled into various parts of the code base.
Some extra work is needed to make ResolveLib really useful as a reusable Python dependency resolver for other projects. One way would be to implement a wrapper library to provide the same Python package semantics to ResolveLib, but with more reusable models such as pypa/packaging, importlib-metadata, etc. The current pip resolver work would be able to offer much knowledge on dealing with various hairy problems, but the code written for pip wouldn’t be directly reusable.
TP
"New Resolver: technical choices" compares various resolvers. https://github.com/pypa/pip/issues/7406 <https://github.com/pypa/pip/issues/7406>
FWICS, more test cases should be the immediate objective.
Factoring out to make a generic resolver would be redundant? Would existing interfaces for e.g. libsolv (dnf) and pycosat (conda) be sufficient?
In theory yes, but the practical problem is that a few ideas in Python packaging can’t be matched cleanly to the general models. Extras (or conditional dependency in general) is one problem a lot of package managers have to deal with outside of the generic resolution process. Another problem is to identify where incompatibilities are declared—version specifiers would be the first coming to mind, but there are actually more, e.g. Requires-Python. All these are solvable problems, and indeed each problem can wire directly to the resolver interface. But they would then all need to solve with the same problems, and likely to each miss something in the process. I believe it would be immensely beneficial to have a “canonical” implementation all parties use and maintain, if only to keep the domain knowledge shared and kept.
On 25/3/2020, at 03:02, Paul Moore <p.f.moore@gmail.com <mailto:p.f.moore@gmail.com>> wrote:
It's already available as a separate package: https://pypi.org/project/resolvelib/ <https://pypi.org/project/resolvelib/>
Paul
On Tue, 24 Mar 2020 at 18:52, Brett Cannon <brett@python.org <mailto:brett@python.org>> wrote:
I couldn't find this in the blog post but is the plan to make the resolver a separate package so other tools can use it? Or is the plan perhaps to get it working in pip first and to break it out later? -- Distutils-SIG mailing list -- distutils-sig@python.org <mailto:distutils-sig@python.org> To unsubscribe send an email to distutils-sig-leave@python.org <mailto:distutils-sig-leave@python.org> https://mail.python.org/mailman3/lists/distutils-sig.python.org/ <https://mail.python.org/mailman3/lists/distutils-sig.python.org/> Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/CLWGX... <https://mail.python.org/archives/list/distutils-sig@python.org/message/CLWGX...>
-- Distutils-SIG mailing list -- distutils-sig@python.org <mailto:distutils-sig@python.org> To unsubscribe send an email to distutils-sig-leave@python.org <mailto:distutils-sig-leave@python.org> https://mail.python.org/mailman3/lists/distutils-sig.python.org/ <https://mail.python.org/mailman3/lists/distutils-sig.python.org/> Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/43NVR... <https://mail.python.org/archives/list/distutils-sig@python.org/message/43NVR...> -- Distutils-SIG mailing list -- distutils-sig@python.org <mailto:distutils-sig@python.org> To unsubscribe send an email to distutils-sig-leave@python.org <mailto:distutils-sig-leave@python.org> https://mail.python.org/mailman3/lists/distutils-sig.python.org/ <https://mail.python.org/mailman3/lists/distutils-sig.python.org/> Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/VLSD5... <https://mail.python.org/archives/list/distutils-sig@python.org/message/VLSD5...>