The dev-repo field is not intuitive

[Drup]

Spawn from #2934

The url inside the dev-repo field and the url given by opam pin FOO <url> are not understood the same way. The CLI has fancy auto detect thing while the opam file does not. To quote @AltGr:

The reason is that when parsing from the command-line, the .git suffix is undestood and magically makes the git backend to be chosen. When parsing from the file, though, doing this magic would be incorrect. If we were doing it, opam pin foo https://foo.bar/toto.git -k http would only work until the end of the current invocation.

Granted, opam-lint now yells about it, but I still believe the design is highly counter intuitive.

[AltGr]

Should I remove the magic from the CLI then ? opam pin https://github.com/foo/bar.git would result in a (broken) http pin that way, which doesn't seem nice. On the other hand, I remain convinced that having a complex logic when parsing the data from files (e.g. https://foo/bar.git means indeed git+https://foo/bar.git, and not actually https://foo/bar.git with the http protocol) is not a good design.

Maybe the issue is with allowing URLs with unspecified protocol (http:// assumes the protocol is http, while that could also be git with http as the transport), and we should have something like http+https://path (or maybe something like curl+https:// ?)
That would cover the ambiguous case, and make it possible to leave the magic protocol-inferring part in the file parsing.

[Drup]

The magic is clearly useful, I do not want to remove it.

I believe your second proposition seems better, but I'm not really sure about how to present it.

[dbuenzli]

On the other hand, I remain convinced that having a complex logic when parsing the data from files (e.g. https://foo/bar.git means indeed git+https://foo/bar.git, and not actually https://foo/bar.git with the http protocol) is not a good design.

I think that from an end user point of view, most of the people won't care, they just want whatever is best, expressed in the easiest form to them. It seems quite evident this form is what mirrors what would happen on git clone http://....

So why not perform the same logic as on the cli and add a dev-repo-kind: field whose semantics mirrors the --kind flag. If you are that user that really wants http with an URI that ends with .git you can then specify http there. So yes this means the sematics of dev-repo: has the "magic" built-in but as long as it's documented and overridable (via dev-repo-kind) it's fine by me.

I also wonder are these vcs+http: actually seen in the wild elsewhere ?

[AltGr]

dev-repo-kind: is similar to what was used in url files, but it doesn't scale, because this issue concerns other fields as well, where e.g. URLs can be part of lists. We need the information locally, so could have something like URL {http}, but it's heavier-weight and ugly.

I don't remember exactly but I checked at the time and vcs+transport:// is relatively common. For example, npm uses it too

[dbuenzli]

dev-repo-kind: is similar to what was used in url files, but it doesn't scale, because this issue concerns other fields as well, where e.g. URLs can be part of lists.

Are you really sure about that ? It seems to me that places where VCS addresses have to be specified is quite limited in the system (url: and dev-repo:).