| 1 |
On 17/09/2015 20:50, Michael Orlitzky wrote: |
| 2 |
> On 09/17/2015 10:03 AM, Alan McKinnon wrote: |
| 3 |
>> Anyone here familiar with driving nodejs and npm? |
| 4 |
>> |
| 5 |
>> I'm trying to write an ebuild for a musicbrainz mirror server and "npm |
| 6 |
>> install" keeps erroring out with one of two errors: |
| 7 |
>> |
| 8 |
>> 1. The install does finish but npm doesn't get around to exiting, |
| 9 |
>> verified by stopping the emerge, running npm install manually and seeing |
| 10 |
>> that it does nothing. When it stalls strace shows the last call was |
| 11 |
>> (poll,<number> ), which implies a race condition. |
| 12 |
>> |
| 13 |
>> 2. More and more often now I get the dreaded "npm: ERR! cb() never |
| 14 |
>> called!" error message which Google and stackoverflow say has been an |
| 15 |
>> ongoing issue for 3 years now. If I keep retrying it eventually |
| 16 |
>> succeeds, implying a race condition of some sort. |
| 17 |
>> |
| 18 |
> |
| 19 |
|
| 20 |
Hi Michael, |
| 21 |
|
| 22 |
I reached pretty much the same conclusions as you. And yes, it is |
| 23 |
src_prepare() not allowing network access that caused most of the |
| 24 |
weirdness. I must have had the packages cached causing them to install |
| 25 |
correctly the first time. I've since cleaned the npm cache and of course |
| 26 |
now they fail. |
| 27 |
|
| 28 |
After I posted my mail I went through the npm bugs at bgo and the |
| 29 |
unstated message from the gentoo devs is loud and clear - "you are not |
| 30 |
putting that shit in the tree" |
| 31 |
|
| 32 |
So I took the easiest possible way out: deleted src_prepare() and issued |
| 33 |
an elog to "cd $inst_dir && npm install, and do not use -g" |
| 34 |
|
| 35 |
> I went through this wonderful experience a few weeks ago. You're not |
| 36 |
> allowed to access the network in src_prepare, so that might be |
| 37 |
> contributing to your weirdness. I came up with two options: |
| 38 |
> |
| 39 |
> 1) Run `npm install` on your dev machine, and then package up the result |
| 40 |
> as a tarball. Generate the manifest from the tarball, and then in your |
| 41 |
> src_install, just copy stuff over. |
| 42 |
> |
| 43 |
> src_install(){ |
| 44 |
> local npm_module_dir="/usr/$(get_libdir)/node/${PN}" |
| 45 |
> insinto "${npm_module_dir}" |
| 46 |
> doins -r whatever |
| 47 |
> ... |
| 48 |
> } |
| 49 |
> |
| 50 |
> |
| 51 |
> This is the lazy way, but avoids you having to package 1,000 other |
| 52 |
> things all written by people who just "learned to code" by googling HOW |
| 53 |
> DO I HTML5. |
| 54 |
|
| 55 |
Agreed. The quality of node software is atrocious, and the package |
| 56 |
manager is even worse. read "npm faq", it is most enlightening and gives |
| 57 |
insight into people's heads.... |
| 58 |
|
| 59 |
> |
| 60 |
> 2) The right way to do it is to use an eclass and install all of the |
| 61 |
> dependencies using separate packages. As you can imagine, this is a |
| 62 |
> nightmare if you have more than a few dependencies (looks like you do). |
| 63 |
|
| 64 |
Errr, no :-) |
| 65 |
|
| 66 |
g-cpan is bad enough and those ebuilds are mostly template-able. At |
| 67 |
least CPAN modules mostly respond correctly to make && make install. |
| 68 |
That node stuff doesn't look like it will ever package sanely. |
| 69 |
|
| 70 |
> |
| 71 |
> I started an eclass for npm packages. I left the overlay here: |
| 72 |
> |
| 73 |
> https://github.com/orlitzky/npm |
| 74 |
> |
| 75 |
> but no one else seemed interested in having it in-tree, and the whole |
| 76 |
> ecosystem is kind of scary to me anyway. |
| 77 |
|
| 78 |
Indeed. |
| 79 |
|
| 80 |
|
| 81 |
> |
| 82 |
> So, for the large package I need, I'm doing it the lazy way: npm install |
| 83 |
> on my machine, and make an ebuild for the resulting huge tarball. |
| 84 |
|
| 85 |
Thanks for the feedback |
| 86 |
|
| 87 |
-- |
| 88 |
Alan McKinnon |
| 89 |
alan.mckinnon@×××××.com |
Archives