'npm update' seems to cause mismatched dependencies. #2390

Closed
bobbydavid opened this Issue Apr 22, 2012 · 5 comments

Comments

Projects
None yet
3 participants
@bobbydavid

When I do a 'npm update', npm does not calculate the dependencies correctly, creating an unstable system.

Repro:

$ uname -a
Linux ubuntu 3.0.0-17-generic-pae #30-Ubuntu SMP Thu Mar 8 17:53:35 UTC 2012 i686 i686 i386 GNU/Linux
$ whoami
robert
$ cd ~/src
$ git clone https://github.com/isaacs/npm.git
$ cd npm
$ ./configure
$ make
<lots of messages>
$ make install
node cli.js install -g -f
/usr/local/bin/npm -> /usr/local/lib/node_modules/npm/bin/npm-cli.js
npm@1.1.18 /usr/local/lib/node_modules/npm
$ npm -g ls
/usr/local/lib
└─┬ npm@1.1.18 
  ├── abbrev@1.0.3 
  ├── archy@0.0.2 
  ├── block-stream@0.0.5 
  ├── chownr@0.0.1 
  ├── fstream@0.1.18 
  ├─┬ fstream-npm@0.0.6 
  │ └── fstream-ignore@0.0.5 
  ├── graceful-fs@1.1.8 
  ├── inherits@1.0.0 
  ├── ini@1.0.2 
  ├── lru-cache@1.0.5 
  ├── minimatch@0.2.2 
  ├── mkdirp@0.3.0 
  ├─┬ node-gyp@0.4.1 
  │ ├── ansi@0.0.4 
  │ └── glob@3.1.9 
  ├── node-uuid@1.3.3 
  ├── nopt@1.0.10 
  ├── proto-list@1.0.0 
  ├── read@0.0.2 
  ├── request@2.9.153 
  ├── rimraf@2.0.1 
  ├── semver@1.0.13 
  ├── slide@1.1.3 
  ├── tar@0.1.13 
  ├── uid-number@0.0.3 
  └── which@1.0.5 
$ npm -g update
... lots of messages ...
$ npm -g ls
npm WARN unmet dependency /usr/local/lib/node_modules/npm/node_modules/node-gyp requires mkdirp@'0.3.0' but will load
npm WARN unmet dependency /usr/local/lib/node_modules/npm/node_modules/mkdirp,
npm WARN unmet dependency which is version 0.3.1
/usr/local/lib
└─┬ npm@1.1.18 
  ├── abbrev@1.0.3 
  ├── archy@0.0.2 
  ├── block-stream@0.0.5 
  ├── chownr@0.0.1 
  ├─┬ fstream@0.1.18 
  │ └── mkdirp@0.3.1 
  ├─┬ fstream-npm@0.0.6 
  │ └─┬ fstream-ignore@0.0.5 
  │   └─┬ minimatch@0.2.4 
  │     └── lru-cache@1.0.6 
  ├── graceful-fs@1.1.8 
  ├── inherits@1.0.0 
  ├── ini@1.0.2 
  ├── lru-cache@1.1.0 
  ├─┬ minimatch@0.2.4 
  │ └── lru-cache@1.0.6 
  ├── mkdirp@0.3.1  invalid
  ├─┬ node-gyp@0.4.1 
  │ ├── ansi@0.0.4 
  │ ├─┬ glob@3.1.9 
  │ │ └─┬ minimatch@0.2.4 
  │ │   └── lru-cache@1.0.6 
  │ ├─┬ minimatch@0.2.4 
  │ │ └── lru-cache@1.0.6 
  │ └── request@2.9.202 
  ├── node-uuid@1.3.3 
  ├── nopt@1.0.10 
  ├── proto-list@1.0.0 
  ├── read@0.0.2 
  ├── request@2.9.202 
  ├── rimraf@2.0.1 
  ├── semver@1.0.13 
  ├── slide@1.1.3 
  ├── tar@0.1.13 
  ├── uid-number@0.0.3 
  └── which@1.0.5 

I can then fix it by doing:

$ npm -g update npm mkdirp
npm http GET https://registry.npmjs.org/npm
npm http 304 https://registry.npmjs.org/npm
npm http GET https://registry.npmjs.org/mkdirp
npm http GET https://registry.npmjs.org/mkdirp/0.3.0
npm http 304 https://registry.npmjs.org/mkdirp/0.3.0
npm http 304 https://registry.npmjs.org/mkdirp
npm http GET https://registry.npmjs.org/mkdirp/0.3.0
npm http 304 https://registry.npmjs.org/mkdirp/0.3.0
mkdirp@0.3.0 /usr/local/lib/node_modules/npm/node_modules/node-gyp/node_modules/mkdirp
$ npm -g ls
/usr/local/lib
└─┬ npm@1.1.18 
  ├── abbrev@1.0.3 
  ├── archy@0.0.2 
  ├── block-stream@0.0.5 
  ├── chownr@0.0.1 
  ├─┬ fstream@0.1.18 
  │ └── mkdirp@0.3.1 
  ├─┬ fstream-npm@0.0.6 
  │ └─┬ fstream-ignore@0.0.5 
  │   └─┬ minimatch@0.2.4 
  │     └── lru-cache@1.0.6 
  ├── graceful-fs@1.1.8 
  ├── inherits@1.0.0 
  ├── ini@1.0.2 
  ├── lru-cache@1.1.0 
  ├─┬ minimatch@0.2.4 
  │ └── lru-cache@1.0.6 
  ├── mkdirp@0.3.1 
  ├─┬ node-gyp@0.4.1 
  │ ├── ansi@0.0.4 
  │ ├─┬ glob@3.1.9 
  │ │ └─┬ minimatch@0.2.4 
  │ │   └── lru-cache@1.0.6 
  │ ├─┬ minimatch@0.2.4 
  │ │ └── lru-cache@1.0.6 
  │ ├── mkdirp@0.3.0 
  │ └── request@2.9.202 
  ├── node-uuid@1.3.3 
  ├── nopt@1.0.10 
  ├── proto-list@1.0.0 
  ├── read@0.0.2 
  ├── request@2.9.202 
  ├── rimraf@2.0.1 
  ├── semver@1.0.13 
  ├── slide@1.1.3 
  ├── tar@0.1.13 
  ├── uid-number@0.0.3 
  └── which@1.0.5 
$ # Now everything is happy.

It appears that during the upgrade, mkdirp@0.3.0 upgrades to mkdirp@0.3.1 -- which would be fine, except that node-gyp@0.4.1 depends on mkdirp@0.3.0. The second, more specific upgrade causes mkdirp@0.3.0 to be re-installed; this time as a dependency of node-gyp@0.4.1.

P.S. This was with the latest version of node.

@isaacs

This comment has been minimized.

Show comment Hide comment
@isaacs

isaacs Jun 4, 2012

Owner

The outdated and update commands are both kind of buggy, and in dire need of a comb-through. Help is welcome!

Owner

isaacs commented Jun 4, 2012

The outdated and update commands are both kind of buggy, and in dire need of a comb-through. Help is welcome!

@bobbydavid

This comment has been minimized.

Show comment Hide comment
@bobbydavid

bobbydavid Jun 6, 2012

What should be the correct behavior in these situations:

  1. Say I install Blaster and it requires the frames@1.5.2 package. I would expect frames to be installed as a subset of Blaster --- but what if I install Asteroid which also uses frames@1.5.2. Should npm "factor" the frames package, and install it at the root level? Or should it be installed twice.

  2. Say I install frames@1.5.2 at the root level, and then install Blaster. I expect it would not have frames as a subset because the requirement is already met. But then I update my packages, and frames moves to frames@1.6.0 while Blaster still requires 1.5.2. Should this trigger frames@1.5.2 to be installed as a sub-package of Blaster?

What should be the correct behavior in these situations:

  1. Say I install Blaster and it requires the frames@1.5.2 package. I would expect frames to be installed as a subset of Blaster --- but what if I install Asteroid which also uses frames@1.5.2. Should npm "factor" the frames package, and install it at the root level? Or should it be installed twice.

  2. Say I install frames@1.5.2 at the root level, and then install Blaster. I expect it would not have frames as a subset because the requirement is already met. But then I update my packages, and frames moves to frames@1.6.0 while Blaster still requires 1.5.2. Should this trigger frames@1.5.2 to be installed as a sub-package of Blaster?

@isaacs

This comment has been minimized.

Show comment Hide comment
@isaacs

isaacs Jun 7, 2012

Owner
  1. No. npm should not automatically flatten.
  2. Yes. npm update should always result in a valid state, no matter what the original state was.
Owner

isaacs commented Jun 7, 2012

  1. No. npm should not automatically flatten.
  2. Yes. npm update should always result in a valid state, no matter what the original state was.
@hbbio

This comment has been minimized.

Show comment Hide comment
@hbbio

hbbio Sep 28, 2012

I don't understand why the first point.

If packages require different version of another package, it's of course logical to have different versions installed.
But when several packages require the same version of another package, I don't see why we should install them multiple times in different subdirectories.

hbbio commented Sep 28, 2012

I don't understand why the first point.

If packages require different version of another package, it's of course logical to have different versions installed.
But when several packages require the same version of another package, I don't see why we should install them multiple times in different subdirectories.

@isaacs

This comment has been minimized.

Show comment Hide comment
@isaacs

isaacs Sep 28, 2012

Owner

That's what the dedupe command is for. Automatically deduping would be a bit more hazardous than I'm willing to do by default.

Owner

isaacs commented Sep 28, 2012

That's what the dedupe command is for. Automatically deduping would be a bit more hazardous than I'm willing to do by default.

@isaacs isaacs closed this Sep 28, 2012

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