In the ideal future would we avoid the build step by having PyPI host primarily wheels? In which case anything available on PyPI would hopefully have its metadata exposed on the JSON endpoint and we could sidestep that.
Either way we will ultimately have to download whatever is specified as a direct url dependency because even if it has a version that aligns we will need to figure out what dependencies it demands, etc etc. And while an optimistic candidate is a neat idea it’s not clear to me at least whether it’s a good idea to expect this of users. What happens when they get it wrong? Do you trust the version in the package or do you allow an override? Conflict resolution is possible either way but the desired behavior there would seem to favor the former imo Dan Ryan // pipenv maintainer gh: @techalchemy > On Jan 29, 2019, at 4:15 PM, Nathaniel Smith <n...@pobox.com> wrote: > > On Tue, Jan 29, 2019, 06:59 Donald Stufft <don...@stufft.io wrote: >>> On Jan 29, 2019, at 9:48 AM, Xavier Fernandez <xav.fernan...@gmail.com> >>> wrote: >>> >>> I disagree that it *needs* the name: since the link is declared as a >>> dependency, the installer will necessarily need to check/download it at >>> some point to install it and could discover the package name at that point, >>> just like it will discover the version at the same point. >>> Providing the name in the direct reference is an optimization that ease the >>> work of the installer and allowing to provide a version specifier could be >>> an other one. >> >> It needs the name to do that without downloading, which is ideally the >> direction we’re heading towards, that we can do as much work prior to >> downloading files as possible. > > > This confused me too, but after thinking about it I think maybe I get it. > > The thing is, there actually is no way for a resolver to know for certain > whether it wants to download a direct URL like this until after it has > downloaded it. Because, you could have a situation where after you download > it, you discover that it has a version, or its own requirements, that are > inconsistent with the other requirements we've gathered, and then the > resolver has to backtrack. And in backtracking it might decide not to use > that exact URL after all. > > But, we can imagine a resolver that works in phases: first, it uses all the > information it can get without downloading/building anything to construct an > optimist candidate solution: "assuming everything I haven't downloaded yet > cooperates, this will work". And then we download/build until either > everything works out, or else we discover some conflict and go back to phase > 1 with more information in our database. > > If package A depends on B and C, and if package B depends on "C @ > some-url"... well, we don't know until we download it whether there different > C requirements are going to match up, it's true. But because the package name > is present in the URL requirement, we at least know that we don't need to go > find C somewhere *else*. If all we had was the URL without the name, then in > this case we might end up downloading C from PyPI, spending time building it, > and only after that download the URL and discover that it was also package C. > > -n > -- > Distutils-SIG mailing list -- distutils-sig@python.org > To unsubscribe send an email to distutils-sig-le...@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/Z3VOS3IB77FY4GLJG3QVEOIKKAAK6GBN/
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@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/AN7CAGSD4XZF33LBJX47COF5IC7EYGRN/
