1 |
On 17/09/2015 22:53, Alec Ten Harmsel wrote: |
2 |
> On Thu, Sep 17, 2015 at 09:24:39PM +0200, Alan McKinnon wrote: |
3 |
>> On 17/09/2015 20:50, Michael Orlitzky wrote: |
4 |
>>> On 09/17/2015 10:03 AM, Alan McKinnon wrote: |
5 |
>>>> Anyone here familiar with driving nodejs and npm? |
6 |
>>>> |
7 |
>>>> I'm trying to write an ebuild for a musicbrainz mirror server and "npm |
8 |
>>>> install" keeps erroring out with one of two errors: |
9 |
> |
10 |
> Haha, npm. First time I ever ran npm, it required 3 runs before it |
11 |
> actually managed to fetch all the dependencies. Hopefully it's better |
12 |
> now. |
13 |
|
14 |
Slightly OT, but the general idea of package management isn't hard. |
15 |
|
16 |
Put the stuff you should have in a list, then compare what you should |
17 |
have to what you do have. Go get and install what you don't have, then |
18 |
make a record that you did it. |
19 |
|
20 |
Everything needed to get these basics right has been known for 40 years |
21 |
or more - fellows like Wirth and Dijkstra figured it all out way back when. |
22 |
|
23 |
Sure, there's always modern stumbling blocks (like why we have subslots) |
24 |
but that's extra to the essential basics. |
25 |
|
26 |
So why oh why do the latest generation of wunderkinds (not) always get |
27 |
it so completely WRONG? 3 runs to fetch all the deps? I suppose wget and |
28 |
curl don't actually do what I think they do then.... |
29 |
|
30 |
> |
31 |
>>> |
32 |
>>> 2) The right way to do it is to use an eclass and install all of the |
33 |
>>> dependencies using separate packages. As you can imagine, this is a |
34 |
>>> nightmare if you have more than a few dependencies (looks like you do). |
35 |
>> |
36 |
>> Errr, no :-) |
37 |
>> |
38 |
>> g-cpan is bad enough and those ebuilds are mostly template-able. At |
39 |
>> least CPAN modules mostly respond correctly to make && make install. |
40 |
>> That node stuff doesn't look like it will ever package sanely. |
41 |
> |
42 |
> Unfortunately, the right way with nodejs/ruby web stuff is to use the |
43 |
> tooling specific to the language. If this[1] is what you're trying to |
44 |
> deploy, I feel sorry. |
45 |
|
46 |
Yes, that's the one |
47 |
|
48 |
> |
49 |
> If I was serious about deploying this, I would: |
50 |
> |
51 |
> 1. Fork the repo and add a remote on my own server |
52 |
> 2. Add your custom configuration |
53 |
> 3. Write a small shell script that |
54 |
> 1. Runs `git pull` from your own infrastructure |
55 |
> 2. Installs perl/node deps locally |
56 |
> 3. Runs the gulp build |
57 |
> 4. Runs plackup |
58 |
> 4. Add an init script that runs that start script |
59 |
|
60 |
I followed that mostly except for forking the repo and writing a small |
61 |
shell script - I much prefer proper ebuilds to hacky scripts. Even |
62 |
though I'm a Linux sysadmin I hate ad-hoc shell scripts with a passion |
63 |
|
64 |
> |
65 |
> This sucks, but it seems to be the way a lot of web stuff is deployed |
66 |
> these days. |
67 |
> |
68 |
> Hope this helps, |
69 |
> |
70 |
> Alec |
71 |
> |
72 |
> [1] https://github.com/metabrainz/musicbrainz-server |
73 |
> |
74 |
|
75 |
|
76 |
-- |
77 |
Alan McKinnon |
78 |
alan.mckinnon@×××××.com |