npm 5.0.1 can't install a specific git dependency #16898
Comments
|
bah humbug. This one requires some explanation... this is all in So! There's some cleverness that npm5 added in order to maximize how often it does shallow clones rather than full clones. I researched all the various restrictions on different kinds of clone to see what could be done, and one thing that stood out was that if we have an actual named ref, then we can (probably?) do a git clone of that ref after getting a remote rev list and seeing if the hash that the user requested is in that list. More succintly, the algo is something like:
I'm not sure off the top of my head why you're getting
Both of these changes would happen pacote-side, but I'll keep this issue open to track it. I think the bulk of the changes needed to do this could be done in pacote's git fetcher, with possibly some tweaks to pacote's git utility depending on the findings. If anyone wants to pick this patch up, I'll help however I can and accept a PR that fixes this over there. @mistydemeo thanks for this report! I'm really glad we found a corner case with my Cunning Plan™. I clearly did not think it all the way through 😂 |
|
Looks like the output of This line is what's transforming |
|
I bet the fix is just to change that command back to |
|
Yeah, I think so: |
|
@mistydemeo would you like to do a PR against pacote, or should I? I definitely lean more towards "MOAR CONTRIBZ" if I can <3 |
|
I'll do a PR! |
|
Please note that github PR refs are actually quite cloneable (origin/pr/123) and it'll be important to retain the ability to npm install a pull request by ref :-) |
GitHub repositories can contain other types of refs, such as pull requests, which can be fetched via `git-fetch` but not cloned via `git clone -b`. Fixes npm/npm#16898.
GitHub repositories can contain other types of refs, such as pull requests, which can be fetched via `git-fetch` but not cloned via `git clone -b`. Fixes npm/npm#16898.
|
@ljharb you should still be able to clone by direct ref -- it just won't hit the fast-path for cloning. Maybe it's worth going back to the no-args version, and doing manual filtering? That's possible, too. Still gotta fix whatever's making |
|
Cool, fast vs slow path is an implementation detail; as long as this fix doesn't break the functionality, I'm happy :-) |
GitHub repositories can contain other types of refs, such as pull requests, which can be fetched via `git-fetch` but not cloned via `git clone -b`. Fixes: npm/npm#16898
|
I getting the following error. (upgraded to 5.0.3 after reading linked threads). Ran chown and chmod 777 for |
|
@shubhamarora try running it as root or sudo if you're gonna be writing to |
|
@zkat I am already running it as root. :| |
|
@shubhamarora ooh interesting. I think I get it. But I'm confused why it worked in older npm versions. I'm lowering permissions for the git process if you have SUDO_UID/SUDO_GID. I'll have to look closer at what npm was doing before -- it was probably working by virtue of creating all the directories earlier. Or not dropping perms the way I thought it was. Cheers, and thanks 👍 |
|
Maybe same problem as @shubhamarora I‘ve just met (after upgraded to 5.0.3): Looks like it can't clone our repos into I've also ran it with sudo, and But work fine after back to [email protected]. SYS: Mac OS X 10.11.6 cc @zkat . |
|
@zkat maybe you can check version 3.10.3 (one I am running currently). Can you help me understand this statement? - "... it was probably working by virtue of creating all the directories earlier. Or not dropping perms the way I thought it was.". And I can help in fixing this if you can guide me? |
|
@shubhamarora There's a new canary, |
|
Hitting this issue as well. @zkat , I tried that: Still failing on pacote |
What |
|
Apologies, maybe this isn't the same issue. At first glance, it seemed to be. |
|
@zkat, i'm still running into an issue. what do you think of this series of commands to test: Versions: The I would have expected that if the new shrinkwrap worked with the old npm version, it should work with the newest one, the one it was created with. |
|
@zkat , though, note that the shallow clone on unsupporting hosts issue does seem to have gone away |
|
@ferrants I can't guarantee that legacy shrinkwraps are going to work with the new package-lock code. The best thing I can recommend is that you regenerate it. |
|
@zkat , I regenerated it with npmc, the new version. That is why I was alarmed when I attempted to |
|
@ferrants that does include not having either an |
|
@zkat hm, I understand your point. how then should I ensure that I keep the same exact versions? if I |
|
same issue, checksum errors #17152 |
|
We're having this problem with node 8.1.0 and npm 5.0.3. package.json has a dependency pointing to a pr ref Call update on this package This kind of update works with npm 3 and 4. On npm 5 we can only pull from I tried origin/pr/* too and no luck (that did not work in npm 3 or 4 for us either). |
@zkat for me that solved problem with 'Permission denied' on git clone. |
|
Does not work with [email protected] Does not work with [email protected] Does not work with [email protected] ( + node 8.1.4). Works with [email protected]. |
|
Getting this error : npm: 5.3.0 |
|
I also want to share my log--note this is in a github.com hosted repo, just using a hash. I'm running as |
|
Having this same exact problem as above with a github.com repo on ubuntu, works fine on my mac. node v8.2.1 |
|
I got error like above $ node -v tmp with 777 permissions |
|
Same using Ubuntu, as regular user and as root: |
|
Having this problem while installing MacOS 10.12.6 |
|
Having similar issue while installing a module that relies on git repo
|
|
It's still relevant. Workaround - |
|
@yanivel Downgrading for npm 3.10.10 worked for me thanks :D |
|
Running this resolved this issue for me: |
|
sudo rm -rf node_modules/ |
EDIT: With a work around that seems to push though the permissions issue
|
|
Thanks for the workaround @zsolt-szabo. It appears that the following combination is still broken:
Switching to root user and then running |
|
I've been encountering this issue for a few months at seemingly random. The heart of the issue was here: Basically, I use root to run my build, and afaict due to npm's uid/guid switching it creates a tmp directory using root but doesn't change permissions so then it can't clone into it. I'd run into the issue, run npm install as non-root, and that'd set the cache so the problem would disappear. It wouldn't show up until I added a new git dependency and tried to build. Anyway, the fix was to not use root to run the build. |
and others
I'm opening this issue because:
What's going wrong?
When I try to install a package which uses a particular git repository at a specific commit, npm tries to
git clonewith the wrong branch and the clone fails. The specific spec ishttps://github.com/github/hubot-slack.git#87f012a8112d52261e1572e05c545b5ae59ababd(or its shorthandgithub/hubot-slack#87f012a8112d52261e1572e05c545b5ae59ababd). Instead of trying to clone at that commit, npm runs the following command:e.g., it's trying to clone branch
11/head. I'm not sure where it's getting that from. npm 3 does fetch this repository/reference correctly.Sorry if this is reported in the wrong project. :) I stepped a module or two down the dependency tree but couldn't quite place what code is responsible for doing the clone and preparing its arguments.
How can the CLI team reproduce the problem?
The following package.json, with a single dependency, reproduces the problem:
{ "name": "repro", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "author": "", "license": "ISC", "dependencies": { "hubot-slack": "https://github.com/github/hubot-slack.git#87f012a8112d52261e1572e05c545b5ae59ababd" } }The debug log is here: https://gist.github.com/283f0f4484d3a8dd7b0cf31acda81b40
supporting information:
npm -vprints: 5.0.1node -vprints: v8.0.0npm config get registryprints: https://registry.npmjs.org/The text was updated successfully, but these errors were encountered: