npm permissions error

[Ryan Schmidt]

On Mar 11, 2012, at 18:47, Jeremy Lavergne wrote:

>> But we are in the business of adding portfiles for software in other package managers. We already do exactly that for perl (cpan), php (pear, pecl), etc. We don't want other package managers installing software into the MacPorts prefix, but that's exactly what "npm -g" (and cpan and pear and pecl) would do. That's why the npm port already prints a message explaining to users that the use of "npm -g" is discouraged. We already have ports for some things you can install with "npm -g", like jake and coffee-script. We should continue adding ports for other such software until nobody feels a need to run "npm -g". 
> 
> Why is MacPorts not actually controlling all these underling package managers? why can't we have MacPorts itself running 'npm -g' and tracking files from there?

Are we talking about something like an npm portgroup with which we could easily whip out ports for each globally-installable npm package? Or modifications to MacPorts base to directly run npm without needing a portfile?


The problem with trying to write an npm portgroup is that there are many things that package managers do that are perfectly fine to do when users control them directly but that we wouldn't want them to do when MacPorts controls them. Some examples from npm (pear, pecl, cpan probably are similar):

npm installs the latest version; we want to install a specific version. Maybe there's a way to tell it what version to use.

npm installs directly to its destination, without using a destroot, so we can't track the files it installs. Maybe there's a way to tell it to use a destroot.

npm downloads files on its own, so we don't get the chance to verify the files' integrity or to mirror them. "port fetch" on some port using this hypothetical npm portgroup would not actually fetch anything; it would fetch during the build phase, which users would not unexpect. Maybe there's a way to tell it to use an already-downloaded distfile.

npm handles dependencies; we want to handle dependencies in MacPorts. npm is unique (as compared with cpan, pear, pecl) in that it allows multiple copies of modules to be installed, in different versions, in different hierarchies. So an npm package foo could depend on version 0.2 of bar and package baz could depend on version 0.4 of bar and npm automatically handles installing them in different directories.

npm only handles npm dependencies, but many npm modules require other compiled libraries, which must already be installed; we need to be able to specify those.

This kind of thing was discussed before for cpan, and again for pecl, and again for pear; the recognition of these various issues is what led Bradley to recently commit hundreds of ports for all the packages available in pear.


Regarding the other idea of having MacPorts directly run npm without needing even a portfile, we would still have the above problems, plus the effort of integrating into base, with the end result that the user has fewer assurances about the software than the few they already have with most other ports. In MacPorts, we at least guarantee users that one other person has confirmed that a port can be installed somewhere. If we were to directly call npm and bypass that approval process, there would be no guarantee at all.