Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement support for PIP-style compat VCS URIs #5522

Open
hvr opened this issue Aug 14, 2018 · 7 comments
Open

Implement support for PIP-style compat VCS URIs #5522

hvr opened this issue Aug 14, 2018 · 7 comments

Comments

@hvr
Copy link
Member

@hvr hvr commented Aug 14, 2018

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
Copy link
Member

@chshersh chshersh commented Aug 14, 2018

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
Copy link
Member

@23Skidoo 23Skidoo commented Aug 14, 2018

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

@quasicomputational
Copy link
Contributor

@quasicomputational quasicomputational commented Aug 14, 2018

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
Copy link
Member

@23Skidoo 23Skidoo commented Aug 14, 2018

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
Copy link
Member

@chshersh chshersh commented Aug 14, 2018

@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
Copy link
Member Author

@hvr hvr commented Aug 14, 2018

@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
Copy link
Collaborator

@gbaz gbaz commented Aug 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.