On Tue, 29 Jan 2019 at 14:23, Donald Stufft <donald@stufft.io> 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 @ https://example.com/foo.tar.gz”. I don’t personally see much of a point to that, the version number doesn’t tell us any new information here, the only thing I think it *could* be useful for, is if you had something depending on “foo >= 1” and something else depending on “foo-1.0 @ …” then it would make it easier to determine there isn’t a dependency conflict.
It could also error if when it downloaded and checked https://example.com/foo.tar.gz it found that it didn't have the name foo and the version 1.0. That would act as a sanity check that the file behind the URL hadn't changed. But it's still just a sanity check based on the user specifying redundant information, and nothing more. 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". People using github URLs in URL specifiers seem to think that it means "check github every time and get me the latest version", which is not even close to what actually happens. 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 expected semantics!) Paul