Package version resolution is a completely different and np-complete problem. https://en.wikipedia.org/wiki/Boolean_satisfiability_problem
On Thu, Aug 30, 2018 at 2:51 PM Chris Jerdonek <chris.jerdo...@gmail.com> wrote: > Broad question: is there a sense in which the same “resolver” logic could > be used for both choosing the best tag, and choosing what versions of > packages to install from abstract requirements, or are these fundamentally > different paradigms that shouldn’t be thought of along the same lines? > > —Chris > > On Thu, Aug 30, 2018 at 11:42 AM Paul Moore <p.f.mo...@gmail.com> wrote: > >> On Thu, 30 Aug 2018 at 19:30, Donald Stufft <don...@stufft.io> wrote: >> > I find it helpful to generally not think of compatibility tags as hard >> “this wheel is supported on this platform”, but more along the lines of “if >> I built a wheel in the specified environment, I would get the same >> results”. Those results may or may not work. So for example, if you have a >> pure Python wheel that *only* works on Python 3.5+, but it produces the >> same output when building the wheel on Python 3.3 (even if it doesn’t >> ultimately work), then a “py3” wheel is the right tag to use. Arguably >> you’d even use py2.py3 since you’d produce the same output (but in practice >> most don’t since that’s extra work). >> >> I also quite like Daniel's description of the list of supported tags >> as "try these, in this order - the first one you match is the best >> chance you have of getting something that works". It may still not >> work, but there's nothing that the package builder declared as being >> any better. >> >> The thing I most dislike about the tag system is that if pip (or any >> installer) misses out a particular tag combination, it gets totally >> ignored. I sort of wish that there was some level of wildcard >> matching, so that weird combinations get picked up at least >> *somewhere* in the priority list. But I never managed to design a >> workable scheme for doing that, so it may not even be possible. >> >> Paul >> -- >> Distutils-SIG mailing list -- distutils-sig@python.org >> To unsubscribe send an email to distutils-sig-le...@python.org >> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ >> Message archived at >> https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/HU2K3CEZPJF7SWRMPGZ5NCULMZIB65NO/ >> > -- > Distutils-SIG mailing list -- distutils-sig@python.org > To unsubscribe send an email to distutils-sig-le...@python.org > https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ > Message archived at > https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/ZZEHWOFEHILLMNXRHXOHKBB3FQZYQNUY/ >
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/HPGE3SSX7BX7WOTWV3LAQX6UYVCILQAT/
