Ah sorry! I was under the impression the “optimistic candidate” was being proposed as one derived from a specifier supplied in the direct dependency line by the user. If it’s a first guess essentially, I think that’s how we operate anyway for the most part (at least in the future resolver) while we step through the dependency graph. My main question is whether you’d consider a dependency specified in pep508 form as satisfying other things that demand the given name even if, upon download, the version doesn’t indicate that. If not, it still feels like we need to download it first. Just because someone put a ref doesn’t mean they don’t update that ref’s content :/ Dan Ryan // pipenv maintainer gh: @techalchemy
On Jan 29, 2019, at 7:15 PM, Nathaniel Smith
wrote: On Tue, Jan 29, 2019 at 4:11 PM Dan Ryan
wrote: 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
Everything I was talking about was stuff that would be happening inside the resolver loop, no users involved. The "optimistic candidate" would just be an initial tentative solution that the resolver uses internally to decide which things to try downloading first.
You know more about how resolvers actually work than I do though, so I might have gotten it wrong :-).
-n
-- Nathaniel J. Smith -- https://vorpus.org