I have started working on an npm eclass but there are some major issues to deal with. What is neat is that jq was just added to Portage which makes parsing JSON on the command line a lot easier (rather than grepping, etc).

In general I think on Gentoo we are going to have to figure out better ways to deal with these 'external' package managers: Maven, npm, gem, etc.

I mainly point to npm because there is a preference developers can specify to recommend that a package be installed globally using -g which by default (since it goes into /usr or /usr/local) requires root privileges. And then of course, the files are not managed as deeply as compared with Portage.

Perhaps the best solution to all of this 'mess' of package managers is to make front-end commands that auto-generate ebuild-lookalikes and run those against Portage (epear, enpm, egem, etc). That way, we still get all the benefits from the real commands, we do not have to wait for ebuilds, and we also get the tremendous benefit of Portage keeping track of files in case we may truly want to uninstall.

IMHO: Really, these package managers just pertain to the 'hipster' programmer Mac users who have no clue what they are doing 99% of the time in my experience. Much like an Ubuntu user who will type sudo make install for some random source they cannot get in that wacky package manager of theirs (that is always out of date) and not think twice about it, a Mac user will also type sudo npm -g.

I have started working on an npm eclass but there are some major issues to deal with.

Nice one :)

One thing I'd say right away, is I don't understand why you mix sh '[' and bash '[[' in the same function. If you're trying to go for sh compatibility in pkg_* then use something like:

Code:

[ -n "$tarball" ] || die "tarball not found in node: '$json'"

If not, just use [[ $tarball ]] || .. and change the other uses of [ to [[; you only need to quote variables in [[ on the RHS of =.

Quote:

I mainly point to npm because there is a preference developers can specify to recommend that a package be installed globally using -g which by default (since it goes into /usr or /usr/local) requires root privileges. And then of course, the files are not managed as deeply as compared with Portage.

Perhaps the best solution to all of this 'mess' of package managers is to make front-end commands that auto-generate ebuild-lookalikes and run those against Portage (epear, enpm, egem, etc). That way, we still get all the benefits from the real commands, we do not have to wait for ebuilds, and we also get the tremendous benefit of Portage keeping track of files in case we may truly want to uninstall.

I don't understand the issue yet. You're installing to a destdir: why should that require root? And doesn't portage already have sufficient permissions?

Quote:

IMHO: Really, these package managers just pertain to the 'hipster' programmer Mac users who have no clue what they are doing 99% of the time in my experience. Much like an Ubuntu user who will type sudo make install for some random source they cannot get in that wacky package manager of theirs (that is always out of date) and not think twice about it, a Mac user will also type sudo npm -g.

It does sound like there are a couple of things to fix in npm. Firstly, that it installs to a destdir without requiring any permission other than the ability to write therein. Secondly that it can be aware of other dependencies already installed. An easy fix would be if you could just tell it not to worry about deps with a flag; that is certainly enough for all distributions.

One thing I'd say right away, is I don't understand why you mix sh '[' and bash '[[' in the same function. If you're trying to go for sh compatibility in pkg_* then use something like:

Code:

[ -n "$tarball" ] || die "tarball not found in node: '$json'"

If not, just use [[ $tarball ]] || .. and change the other uses of [ to [[; you only need to quote variables in [[ on the RHS of =.

To be honest, not really trying to be compatible with any particular shell. Sometimes I forget what is compatible with which.

steveL wrote:

Quote:

I mainly point to npm because there is a preference developers can specify to recommend that a package be installed globally using -g which by default (since it goes into /usr or /usr/local) requires root privileges. And then of course, the files are not managed as deeply as compared with Portage.

Perhaps the best solution to all of this 'mess' of package managers is to make front-end commands that auto-generate ebuild-lookalikes and run those against Portage (epear, enpm, egem, etc). That way, we still get all the benefits from the real commands, we do not have to wait for ebuilds, and we also get the tremendous benefit of Portage keeping track of files in case we may truly want to uninstall.

I don't understand the issue yet. You're installing to a destdir: why should that require root? And doesn't portage already have sufficient permissions?

Portage on a regular system (non-prefix) generally requires root. That is really the only reason why. Yes, it has sufficient permissions.

steveL wrote:

Quote:

IMHO: Really, these package managers just pertain to the 'hipster' programmer Mac users who have no clue what they are doing 99% of the time in my experience. Much like an Ubuntu user who will type sudo make install for some random source they cannot get in that wacky package manager of theirs (that is always out of date) and not think twice about it, a Mac user will also type sudo npm -g.

It does sound like there are a couple of things to fix in npm. Firstly, that it installs to a destdir without requiring any permission other than the ability to write therein. Secondly that it can be aware of other dependencies already installed. An easy fix would be if you could just tell it not to worry about deps with a flag; that is certainly enough for all distributions.

On your first point yes. My guess is that they ask for npm -g is because almost any UNIX system has /usr/local/bin and that is already in $PATH, as opposed to installing to ~/.node/bin or similar and instructing the user to modify $PATH or attempting to set it for them. For libraries it does not matter. $PWD/node_modules is fine there, but for scripts like jshint which are useful on a system-level (not just a project level), I think it would be better to have Portage do it where we have something working well already.

I guess I just want things to be always managed with Portage when they go into /usr or similar places. I do not tend to use /usr/local as a 'dumping ground' for random stuff (as I have seen others use it for; my /usr/local is empty). If the files are in $HOME I do not care if they are managed or not that much, and I do not seek to have Portage help there.

Edit: I updated the eclass to use Bash syntax on the tarball URI check.