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

2019-03-18 Thread Simon
Admittedly, HTTP Basic Auth is better than nothing, but it's hard to get excited about setting that up and either managing an extra set of credentials, or hooking it up to a single-signon system, when the SSH-based authentication is already set up to control access to the source repositories. On

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

2019-03-15 Thread Tzu-ping Chung
> On 15 Mar 2019, at 21:47, Simon Ruggier wrote: > > The packages have to be available online for dependency links to work, yes, > but they're not public: one needs to authenticate with an SSH key to clone > each repository. Both --find-links and --index-url (or --extra-index-url) provide

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

2019-03-13 Thread Tzu-ping Chung
> On 6 Mar 2019, at 03:53, Simon wrote: > > I hope it's not an issue that I'm replying to a month-old thread. I reviewed > the previous discussion to try to avoid duplicating any of it. > > When using pip with PyPI, calling pip a second time is much quicker than the > first time, because it

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

2019-03-13 Thread Simon
I hope it's not an issue that I'm replying to a month-old thread. I reviewed the previous discussion to try to avoid duplicating any of it. When using pip with PyPI, calling pip a second time is much quicker than the first time, because it verifies that the requirements, including version

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

2019-01-31 Thread Paul Moore
On Thu, 31 Jan 2019 at 09:07, Jan Musílek wrote: > Sure, I'll get to it. Just seen your summary. Very nice, thanks! If any questions arise as a result that you would like me to chip in on, feel free to ping me on the issue. Paul -- Distutils-SIG mailing list -- distutils-sig@python.org To

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

2019-01-31 Thread Jan Musílek
> Do you think you'd be able to summarise the conclusions from this > thread on the pip issue that prompted it? It would be nice if we could > record it over there for people who are following the tracker issue, > and an explanation from an "affected user" perspective may be more > helpful to

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

2019-01-29 Thread Dan Ryan
l.com] Sent: Tuesday, January 29, 2019 11:56 PM To: Donald Stufft Cc: Distutils Subject: [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

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

2019-01-29 Thread Tzu-ping Chung
> 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

2019-01-29 Thread Chris Jerdonek
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] Re: Update PEP 508 to allow version specifiers

2019-01-29 Thread Dan Ryan
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

2019-01-29 Thread Dan Ryan
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

2019-01-29 Thread Nathaniel Smith
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

2019-01-29 Thread Tres Seaver
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

2019-01-29 Thread Nathaniel Smith
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

2019-01-29 Thread Paul Moore
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

2019-01-29 Thread Jan Musílek
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

2019-01-29 Thread Paul Moore
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

2019-01-29 Thread Donald Stufft
> 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

2019-01-29 Thread Xavier Fernandez
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

2019-01-29 Thread Thomas Kluyver
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

2019-01-29 Thread 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 package name at that point, just > like

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

2019-01-29 Thread Donald Stufft
> 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

2019-01-29 Thread Xavier Fernandez
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

2019-01-29 Thread Paul Moore
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

2019-01-29 Thread Donald Stufft
> 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

2019-01-29 Thread Xavier Fernandez
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

2019-01-29 Thread Nick Coghlan
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

2019-01-29 Thread Paul Moore
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

2019-01-29 Thread Nick Coghlan
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

2019-01-29 Thread Donald Stufft
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

2019-01-29 Thread Bernat Gabor
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

2019-01-29 Thread Jan Musílek
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

2019-01-29 Thread Nick Coghlan
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

2019-01-29 Thread Paul Moore
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

2019-01-29 Thread Jan Musílek
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

2019-01-29 Thread Paul Moore
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

2019-01-29 Thread Jan Musílek
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

2019-01-29 Thread 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 package version. -- Tzu-ping Chung (@uranusjr) uranu...@gmail.com Sent from my iPhone >