On 17/09/2015 22:53, Alec Ten Harmsel wrote: > On Thu, Sep 17, 2015 at 09:24:39PM +0200, Alan McKinnon wrote: >> On 17/09/2015 20:50, Michael Orlitzky wrote: >>> On 09/17/2015 10:03 AM, Alan McKinnon wrote: >>>> Anyone here familiar with driving nodejs and npm? >>>> >>>> I'm trying to write an ebuild for a musicbrainz mirror server and "npm >>>> install" keeps erroring out with one of two errors: > > Haha, npm. First time I ever ran npm, it required 3 runs before it > actually managed to fetch all the dependencies. Hopefully it's better > now.
Slightly OT, but the general idea of package management isn't hard. Put the stuff you should have in a list, then compare what you should have to what you do have. Go get and install what you don't have, then make a record that you did it. Everything needed to get these basics right has been known for 40 years or more - fellows like Wirth and Dijkstra figured it all out way back when. Sure, there's always modern stumbling blocks (like why we have subslots) but that's extra to the essential basics. So why oh why do the latest generation of wunderkinds (not) always get it so completely WRONG? 3 runs to fetch all the deps? I suppose wget and curl don't actually do what I think they do then.... > >>> >>> 2) The right way to do it is to use an eclass and install all of the >>> dependencies using separate packages. As you can imagine, this is a >>> nightmare if you have more than a few dependencies (looks like you do). >> >> Errr, no :-) >> >> g-cpan is bad enough and those ebuilds are mostly template-able. At >> least CPAN modules mostly respond correctly to make && make install. >> That node stuff doesn't look like it will ever package sanely. > > Unfortunately, the right way with nodejs/ruby web stuff is to use the > tooling specific to the language. If this[1] is what you're trying to > deploy, I feel sorry. Yes, that's the one > > If I was serious about deploying this, I would: > > 1. Fork the repo and add a remote on my own server > 2. Add your custom configuration > 3. Write a small shell script that > 1. Runs `git pull` from your own infrastructure > 2. Installs perl/node deps locally > 3. Runs the gulp build > 4. Runs plackup > 4. Add an init script that runs that start script I followed that mostly except for forking the repo and writing a small shell script - I much prefer proper ebuilds to hacky scripts. Even though I'm a Linux sysadmin I hate ad-hoc shell scripts with a passion > > This sucks, but it seems to be the way a lot of web stuff is deployed > these days. > > Hope this helps, > > Alec > > [1] https://github.com/metabrainz/musicbrainz-server > -- Alan McKinnon [email protected]
