| View previous topic :: View next topic |
| Author |
Message |
Tatsh
Apprentice
Joined: 22 Jul 2007
Posts: 187
|
 Posted: Wed May 01, 2013 1:28 pm Post subject: npm eclass, external package managers |
 |
|
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).
Code is here: https://github.com/Tatsh/tatsh-overlay/blob/master/eclass/npm.eclass
First ebuild: https://github.com/Tatsh/tatsh-overlay/blob/master/dev-js/jshint/jshint-1.1.0.ebuild
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. |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed May 01, 2013 7:44 pm Post subject: Re: npm eclass, external package managers |
|
|
| Tatsh wrote: | | 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. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Wed May 01, 2013 8:07 pm Post subject: |
|
|
| It doesn't make sense to drop to sh-compatible syntax in an ebuild anyway; the PMS already requires bash. |
|
| Back to top |
|
|
Tatsh
Apprentice
Joined: 22 Jul 2007
Posts: 187
|
| Posted: Sat May 04, 2013 5:31 am Post subject: Re: npm eclass, external package managers |
|
|
| steveL wrote: |
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. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
