dependency http://*.git should be resolved as git repository during `npm install` #4060

Closed
robrich opened this Issue Oct 30, 2013 · 6 comments

Comments

Projects
None yet
4 participants
@robrich

robrich commented Oct 30, 2013

Consider this fragment from a package.json:

"dependencies": {
    "foo": "https://github.com/isaacs/read-package-json.git"
}

Because this url ends in ".git", rather than treating this as a tarball instead treat it as a git repository. This would augment GitHub URLs to also allow for private Git repositories, GitHub Enterprise, etc.

@luk-

This comment has been minimized.

Show comment
Hide comment
@luk-

luk- Oct 30, 2013

Contributor

You can currently do that with any of these as the value
git://github.com/user/repo.git
git+https://user@github.com/user/repo.git
git+ssh://git@github.com:user/repo.git

Contributor

luk- commented Oct 30, 2013

You can currently do that with any of these as the value
git://github.com/user/repo.git
git+https://user@github.com/user/repo.git
git+ssh://git@github.com:user/repo.git

@luk- luk- closed this Oct 30, 2013

@luk-

This comment has been minimized.

Show comment
Hide comment
@luk-

luk- Oct 30, 2013

Contributor

This could be a good point for discussion: is assuming a dependency whose location begins with an HTTP URI scheme is a tarball too magic?

Should we consider file extensions, then attempt git+https ourselves on a URI that ends in .git?

It might be a good idea unless I'm overlooking some technical reasons for how we currently do things. Either way, the functionality you're looking for exists now, even if this could be a nice change in the future.

Contributor

luk- commented Oct 30, 2013

This could be a good point for discussion: is assuming a dependency whose location begins with an HTTP URI scheme is a tarball too magic?

Should we consider file extensions, then attempt git+https ourselves on a URI that ends in .git?

It might be a good idea unless I'm overlooking some technical reasons for how we currently do things. Either way, the functionality you're looking for exists now, even if this could be a nice change in the future.

@luk- luk- reopened this Oct 30, 2013

@robrich

This comment has been minimized.

Show comment
Hide comment
@robrich

robrich Oct 30, 2013

I agree: assuming it's a tarball is too magic. I'd further suggest that tarball is likely not a frequent use-case, and transitioning tarballs away from purely a url to perhaps tar+https://someurl.com/path/to/ball.tar.gz makes the intention more clear.

robrich commented Oct 30, 2013

I agree: assuming it's a tarball is too magic. I'd further suggest that tarball is likely not a frequent use-case, and transitioning tarballs away from purely a url to perhaps tar+https://someurl.com/path/to/ball.tar.gz makes the intention more clear.

@luk-

This comment has been minimized.

Show comment
Hide comment
@luk-

luk- Oct 31, 2013

Contributor

A lot of this has to do with how npm handles dependencies normally (via a tarball from the registry). So tarballs aren't going away anytime soon or getting handled as a second class citizen, but maybe someday there can be magic support for other file extensions.

Contributor

luk- commented Oct 31, 2013

A lot of this has to do with how npm handles dependencies normally (via a tarball from the registry). So tarballs aren't going away anytime soon or getting handled as a second class citizen, but maybe someday there can be magic support for other file extensions.

@rlidwka

This comment has been minimized.

Show comment
Hide comment
@rlidwka

rlidwka Oct 31, 2013

Contributor

If you like magic, it is possible to mimic git behaviour and check if a remote application supports git protocol with one separate request. For example, it can be used as a fallback after tarball download fails.

curl -D - https://github.com/isaacs/npm.git/git-upload-pack -X POST \
     -H  'Content-Type: application/x-git-upload-pack-request' \
     -H  'Accept: application/x-git-upload-pack-result' \
     -H  'User-Agent: git/1.8.3.2'

HTTP/1.1 200 OK
Server: GitHub.com
Date: Thu, 31 Oct 2013 05:13:59 GMT
Content-Type: application/x-git-upload-pack-result
Expires: Fri, 01 Jan 1980 00:00:00 GMT
Pragma: no-cache
Cache-Control: no-cache, max-age=0, must-revalidate
Content-Length: 0
Vary: Accept-Encoding
Contributor

rlidwka commented Oct 31, 2013

If you like magic, it is possible to mimic git behaviour and check if a remote application supports git protocol with one separate request. For example, it can be used as a fallback after tarball download fails.

curl -D - https://github.com/isaacs/npm.git/git-upload-pack -X POST \
     -H  'Content-Type: application/x-git-upload-pack-request' \
     -H  'Accept: application/x-git-upload-pack-result' \
     -H  'User-Agent: git/1.8.3.2'

HTTP/1.1 200 OK
Server: GitHub.com
Date: Thu, 31 Oct 2013 05:13:59 GMT
Content-Type: application/x-git-upload-pack-result
Expires: Fri, 01 Jan 1980 00:00:00 GMT
Pragma: no-cache
Cache-Control: no-cache, max-age=0, must-revalidate
Content-Length: 0
Vary: Accept-Encoding
@othiym23

This comment has been minimized.

Show comment
Hide comment
@othiym23

othiym23 May 20, 2016

Contributor

The CLI team are unanimously agreed that magic is terrible, but at this point the convention of using HTTP[S] URLs to refer to tarballs (and only to refer to tarballs) is sufficiently deeply engrained that it doesn't seem worth the effort to try to change it by making it explicit. As such, I'm going to close this out. Thanks to all for the time and discussion.

Contributor

othiym23 commented May 20, 2016

The CLI team are unanimously agreed that magic is terrible, but at this point the convention of using HTTP[S] URLs to refer to tarballs (and only to refer to tarballs) is sufficiently deeply engrained that it doesn't seem worth the effort to try to change it by making it explicit. As such, I'm going to close this out. Thanks to all for the time and discussion.

@othiym23 othiym23 closed this May 20, 2016

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