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

Comments

@hvr
Member

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

This comment has been minimized.

Show comment
Hide comment
@ChShersh

ChShersh Aug 14, 2018

Member

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
Member

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
@23Skidoo

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Aug 14, 2018

Member

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

Member

23Skidoo commented Aug 14, 2018

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

@quasicomputational

This comment has been minimized.

Show comment
Hide comment
@quasicomputational

quasicomputational Aug 14, 2018

Collaborator

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?

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Aug 14, 2018

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@ChShersh

ChShersh Aug 14, 2018

Member

@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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@hvr

hvr Aug 14, 2018

Member

@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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@gbaz

gbaz Aug 14, 2018

Collaborator
Collaborator

gbaz commented Aug 14, 2018

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