Implement support for PIP-style compat VCS URIs

[hvr]

This ticket quickly summarises a feature enhancement @typedrat and I discussed for the current GSOC

Currently the VCS syntax in cabal.project files is rather clunky; but fortunately there's prior art we can steal from other ecosystems, specifically from Python's PIP VCS Support

The goal is to have the more compact syntax (which must be valid RFC 3986) as shown below in the non-exhaustive example

packages:
   git+https://github.com/well-typed/cborg@3d274c14ca3077c3a081ba7ad57c5182da65c8c1#subdir=cborg
   git+https://github.com/serokell/time-units.git@6c3747c1ac794f952de996dd7ba8a2f6d63bf132

be syntax sugar for the more verbose source-repository-package based specification

source-repository-package
    type: git
    location: https://github.com/well-typed/cborg
    tag: 3d274c14ca3077c3a081ba7ad57c5182da65c8c1
    subdir: cborg

source-repository-package
    type: git
    location: https://github.com/serokell/time-units.git
    tag: 6c3747c1ac794f952de996dd7ba8a2f6d63bf132

NB: entries in packages: must be able to disambiguate the following 4 categories

• filepaths pointing to local package folders or .cabal files (e.g. ./mypkg/ or /foo/bar/doo.cabal or ./deps/*)
• filepaths pointing to local package source-tarballs (e.g. ./deps/foo-1.2.3.tar.gz or deps/*.tar.gz)
• remote HTTP(s) locations pointing to package source tarballs (e.g. https://hackage.haskell.org/package/stm-2.5.0.0/candidate/stm-2.5.0.0.tar.gz)
• URIs denoting remote VCS locations (i.e. this ticket's scope; this is easy to disambiguate because we require valid RFC3986 syntax; and the uri scheme always contains a token to indicate the VCS-type, e.g. git)

(fwiw, should the need arise that the local-filepath interpretation may not be properly detected, one could use explicit file:/// uris to explicitly disambiguate and force interpretation as a local filepath)

This is a preliminary vague specifications; more details TBD

Follow-up stretch-goal: have new-install support vcs uris as well (TBD in separate ticket)

[chshersh]

One minor comment. It would be great if instead of:

git+https://github.com/well-typed/cborg@3d274c14ca3077c3a081ba7ad57c5182da65c8c1#subdir=cborg

it would be possible to write:

github+well-typed/cborg@3d274c14ca3077c3a081ba7ad57c5182da65c8c1#subdir=cborg

UPD: Please, don't downvote. After more discussion and thinking I've realized that this is not a good idea.

[23Skidoo]

@chshersh GitHub allows both SSH and HTTPS access, how do you distinguish between them with this notation?

[quasicomputational]

Isn't HTTPS the right choice here, since it's a read-only clone and HTTPS doesn't require messing about with public keys, unlike SSH?

[23Skidoo]

The user may want SSH for some reason. Anyway, I'm inclined to follow existing precedent for this syntax without inventing our own extensions, at least initially.

[chshersh]

@quasicomputational You also may want to have SSH access when you're depending on private GitHub repository and you don't want to type password each time you build project after changing commit tag.

[hvr]

@chshersh I'm strongly against hardcoding github or any other git repo hoster into our logic; let's just stick to standardised URI schemes and not invent redundant ones for proprietary companies (which may come across as some form of endorsement for those we support; and I'd also not want to have to maintain a database in cabal mapping aliases to URI/DNS expansions; so this would also violate the KISS principle if we took on that concern). Moroever, the example you give with github (which does not qualify as URI protocol scheme; github isn't a new protocol, it's just a redundant alias) would weaken the already ambiguous grammar even more.

[gbaz]

According to the linked pip, as i would expect, one specifies ssh instead of https by using ssh:// rather than https:// as the protocol.