[Distutils] Re: Update PEP 508 to allow version specifiers

> but I guess it could be interpreted as “you can find the package here, and I > promise it satisfies the given specifiers Promising to satisfy a vague constraint isn’t very useful though, is it? Since it’s not providing a strict pin you aren’t even getting enough information to leverage

[Distutils] Re: Update PEP 508 to allow version specifiers

> On 29 Jan 2019, at 23:19, Donald Stufft wrote: > >> On Jan 29, 2019, at 10:15 AM, Xavier Fernandez >> wrote: >> >> I agree that such specifier would make little sense but why add a new syntax >> "foo-1 @ url" when "foo==1 @ url" (where ==1 is a version specifier as >> defined in PEP 508)

[Distutils] 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

[Distutils] PEP 517 Backend boostrapping

Bundled up in the confusion about the PEP 517 rollout is the issue that PEP 517 does not allow for PEP 517 backends to use PEP 517 to build themselves, and how the bootstrapping should take place is left unspecified. This is a problem for setuptools at the moment, and presumably other build

[Distutils] Re: Update PEP 508 to allow version specifiers

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)

[Distutils] Re: Update PEP 508 to allow version specifiers

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

[Distutils] Re: Update PEP 508 to allow version specifiers

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

[Distutils] Re: Update PEP 508 to allow version specifiers

On 1/29/19 9:43 AM, Paul Moore wrote: > And when they start adding > version numbers to that (like the OP's package >= 10.0 @ > https://github.com/owner/package.git) I can't even begin to understand > what they think it might mean. (Hence my original request for a better > explanation of the

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, Jan 29, 2019, 06:59 Donald Stufft On Jan 29, 2019, at 9:48 AM, Xavier Fernandez > 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

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, 29 Jan 2019 at 15:49, Jan Musílek wrote: > > Thank you all for very helpful comments! Thank you for bringing this up. > I've carefully considered everything you said and I'm now mostly convinced, > that PEP 508 actually doesn't need to be expanded to include version > specifiers.

[Distutils] Re: Update PEP 508 to allow version specifiers

Thank you all for very helpful comments! I've carefully considered everything you said and I'm now mostly convinced, that PEP 508 actually doesn't need to be expanded to include version specifiers. Sure, if it would, some workflows will continue to work more or less as they were. But it's not

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, 29 Jan 2019 at 15:07, Thomas Kluyver wrote: > > On Tue, Jan 29, 2019, at 2:43 PM, Paul Moore wrote: > > And when they start adding > > version numbers to that (like the OP's package >= 10.0 @ > > https://github.com/owner/package.git) I can't even begin to understand > > what they think it

[Distutils] Re: Update PEP 508 to allow version specifiers

> On Jan 29, 2019, at 10:15 AM, Xavier Fernandez > wrote: > > I agree that such specifier would make little sense but why add a new syntax > "foo-1 @ url" when "foo==1 @ url" (where ==1 is a version specifier as > defined in PEP 508) would perfectly fit the bill ? Well foo-1 wouldn’t work

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, Jan 29, 2019 at 3:58 PM Donald Stufft wrote: > A version specifier is something like “>=10”. It doesn’t make any sense to > say “I depend explicitly on the version of foo that exists at this URL, and > also that URL has to be >= 10”. You’re already telling us that you depend > on that

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, Jan 29, 2019, at 2:43 PM, Paul Moore wrote: > And when they start adding > version numbers to that (like the OP's package >= 10.0 @ > https://github.com/owner/package.git) I can't even begin to understand > what they think it might mean. I presume the idea is that it uses that repository

[Distutils] Re: Update PEP 508 to allow version specifiers

> On Jan 29, 2019, at 9:48 AM, Xavier Fernandez 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

[Distutils] Re: Update PEP 508 to allow version specifiers

> On Jan 29, 2019, at 9:43 AM, Paul Moore wrote: > > But direct URLs to github repos are a different matter, and are > frankly just wrong - by their nature a github repo is a changing > object, and so will never map to a "specific artifact to install". FWIW, Paul’s statement is supported by

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, Jan 29, 2019 at 3:22 PM Donald Stufft wrote: > > It still declares a name in the specifier because when doing the > dependency resolution algorithm, it needs to know the name and the version, > and conceptually the name and version of “foo @ > https://example.com/foo.tar.gz” is (“foo”,

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, 29 Jan 2019 at 14:23, Donald Stufft wrote: > However, one thing we *could* maybe do is allow including a specific version. > So instead of treating the URL as the version you would provide the name, > version, and url. So you’d have something like "foo-1.0 @ >

[Distutils] Re: Update PEP 508 to allow version specifiers

> On Jan 29, 2019, at 9:02 AM, Xavier Fernandez wrote: > > Thanks Jan for raising this issue. > > On Tue, Jan 29, 2019 at 10:21 AM Tzu-ping Chung > wrote: > I’m wondering, why is it needed to specify both a version and a link? I > assume the version specifier

[Distutils] Re: Update PEP 508 to allow version specifiers

Thanks Jan for raising this issue. On Tue, Jan 29, 2019 at 10:21 AM Tzu-ping Chung wrote: > I’m wondering, why is it needed to specify both a version and a link? I > assume the version specifier would be redundant when a link is provided > as the source, since the link can only point to one

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, 29 Jan 2019 at 23:40, Donald Stufft wrote: > > You can also just stick files in a directory and use pretty much any web > server that generates an automatic index from it. Including python3 -m http.server! (I wouldn't recommend using that on the public internet, but it can be very handy

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, 29 Jan 2019 at 13:16, Nick Coghlan wrote: > > On Tue, 29 Jan 2019 at 20:09, Paul Moore wrote: > > OK, I think that it may well be in that case that URL specifiers don't > > satisfy that specific use case that dependency_links did[1]. But URL > > specifiers were *intended* to replace

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, 29 Jan 2019 at 23:29, Jan Musílek wrote: > > Nick Coghlan wrote: > > So URL specifiers replaced the part of dependency links that we > > actually wanted to keep: letting projects *temporarily* depend on VCS > > repos and other URLs while waiting for a release containing the > > feature

[Distutils] Re: Update PEP 508 to allow version specifiers

You can also just stick files in a directory and use pretty much any web server that generates an automatic index from it. > On Jan 29, 2019, at 8:35 AM, Bernat Gabor wrote: > > I'm not sure I agree that setting up a private repository is that hard. Devpi > does an excellent job for open

[Distutils] Re: Update PEP 508 to allow version specifiers

I'm not sure I agree that setting up a private repository is that hard. Devpi does an excellent job for open source stuff, or otherwise if you use Artifactory inside your company that also has similar plugin. On Tue, Jan 29, 2019 at 1:30 PM Jan Musílek wrote: > Nick Coghlan wrote: > > So URL

[Distutils] Re: Update PEP 508 to allow version specifiers

Nick Coghlan wrote: > So URL specifiers replaced the part of dependency links that we > actually wanted to keep: letting projects *temporarily* depend on VCS > repos and other URLs while waiting for a release containing the > feature that they needed, while focusing on abstract dependencies >

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, 29 Jan 2019 at 20:09, Paul Moore wrote: > > On Tue, 29 Jan 2019 at 09:51, Jan Musílek wrote: > > Well, yes, that's basically it. I don't think that there is anything wrong > > with PEP 508 pointing only at specific versions. BUT, it's widely proposed > > as replacement for dependency

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, 29 Jan 2019 at 09:51, Jan Musílek wrote: > Well, yes, that's basically it. I don't think that there is anything wrong > with PEP 508 pointing only at specific versions. BUT, it's widely proposed as > replacement for dependency links, which it's clearly not because of this > issue. OK,

[Distutils] Re: Update PEP 508 to allow version specifiers

Paul Moore wrote: > On Tue, 29 Jan 2019 at 09:20, Tzu-ping Chung > I’m wondering, why is it needed to specify both a version and a link? I > > assume the > > version specifier would be redundant when a link is provided as the source, > > since the link > > can only point to one possible

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, 29 Jan 2019 at 09:20, Tzu-ping Chung wrote: > > I’m wondering, why is it needed to specify both a version and a link? I > assume the version specifier would be redundant when a link is provided as > the source, since the link can only point to one possible package version. From what I

[Distutils] Re: Update PEP 508 to allow version specifiers

Paul Moore wrote: > Maybe the way to define useful semantics here would be to articulate > the actual problem you're trying to solve (*without* referring to how > dependency_links works) and propose a semantics that solves that > problem? Lets say that have project A, that has requirements B and

[Distutils] Re: Update PEP 508 to allow version specifiers

I’m wondering, why is it needed to specify both a version and a link? I assume the version specifier would be redundant when a link is provided as the source, since the link can only point to one possible package version. -- Tzu-ping Chung (@uranusjr) uranu...@gmail.com Sent from my iPhone >

[Distutils] Update PEP 508 to allow version specifiers

Hello! I hope I'm addressing this issue to the right place. Pradyun Gedam suggested [1] to open the discussion here. PEP 508 dependency specification [2] is generally considered to be replacement for dependency links. However, version specifiers are missing from PEP 508, so I can't specify: