Re: Update PEP 508 to allow version specifiers

Given the confusion / lack of awareness around these issues, would it
make sense for pip to point users towards an explanation and/or
available work-arounds if pip sees that a user is trying to use the
feature (e.g. if a user tries adding a version specifier or tries to
use dependency links in general)?

--Chris

On Tue, Jan 29, 2019 at 5:08 PM Dan Ryan <[email protected]> wrote:
>
> 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 <[email protected]> wrote:
> >
> >> On Tue, Jan 29, 2019 at 4:11 PM Dan Ryan <[email protected]> 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
> --
> Distutils-SIG mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> Message archived at https://mail.python.org/archives/list/[email protected]/message/QRKFG4CNRJVRAXMUHA6RLKJ55V4QMRMK/
--
Distutils-SIG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/archives/list/[email protected]/message/KN6NOZFVLGB4WVMJXNZRGHI7WC5K3OM4/