I'm attempting to write the ebuild for #461870. The problem I'm running into is the node package dependencies that are installed with npm. I don't want to run `npm install ...` unless I need to. It would be nice if portage did these dependency checks for us. The crappy way to address this issue (as discussed before http://forums.gentoo.org/viewtopic-t-902918-start-0.html) would be to make ebuilds for all of the npm packages, or at least the popular ones. This would be a nightmare to maintain. Thinking about it a little, I had an idea for how to handle this. I would like some input, especially relating to if this is even possible given the current portage architecture. What if we reserve a package category and treat that as an alias to npm's namespace? emerge, in this example case, would then just do the translation from gentoo's conventions to npm's naming and versioning standards and call `npm install -g ...`. For example, these two lines would have the same effect: npm install -g coffee-script@1.4 emerge -q =ext-npm/coffee-script-1.4 I imagine this solution could be applied to other package managers that are difficult to interface to emerge. Is it worth having this discussion on the forums instead?
For things like this, typically an external tool is created to generate ebuilds. For example, app-portage/g-cpan is available to generate ebuilds for perl modules and bundles from CPAN: http://www.gentoo.org/proj/en/perl/g-cpan.xml Eventually, it would be possible to integrate tools like g-cpan with emerge (or layman), so that you wouldn't have to call them directly. It might make more sense to try to integrate it with layman first, since layman already does the job of managing overlays.
A few things to consider: - node_modules nest on every package. You have prune and dedupe available, but you will run into version conflicts - gyp support for all c/c++ node modules. You'll also run into similar problems as above, only worse. Also consider how multilib would come into play. - Some modules acts as installers and downloads all kinds of stuff (sorry for not being specific, couldn't find a good enough example at the moment -- but I've encountered this numerous times over the years I've been using nodejs). If we want to treat this seriously, I'm all for it; but from my current position (as co-maintainer of nodejs), its a lot of trees.
More things to consider: - nodejs needs to be slotted (at least stable versions; 0.8, 0.10 and soon 0.12) since a wide range of packages doesn't support all versions - we'd have to patch the gyp build to use our environment (node-gyp) - it's pretty common for packages to lock down their dependencies in package.json. This will make it super hard for us to dedupe properly. We'd actually have to run dedupe/prune on every package install (if we care about having a slim system).
In the current discussion on gentoo-dev, neurogeek pointed to https://github.com/neurogeek/g-npm : interesting.
No.
First of all, this can't really work well. Different package managers are just too different to handle 1:1 mapping like this. You can look into g-cpan and similar tools to see how bad the ebuilds can be, and how much extra work they require afterwards. Using npm directly would be even worse. Secondly, Portage is not really the place to do this. Even if we supported such a thing, you won't be able to commit a single ebuild relying on it. For that, you'd need it in the PMS and you can guess how far a not-well-drafted, complex feature like this can go...
