NDM

[piranna]

https://github.com/npm/ndm

Seems it could integrate really well with NodeOS services... or maybe also reemplace it (at least at the user administration level) :-)

[seanewest]

I'm really into this idea. It would make NodeOS more minimal and would encourage package authors to publish services that would work across different OS's (ndm currently supports Mac, Ubuntu, and CentOS).

I currently have a PR in ndm to allow for global npm packages to be used directly as services. I think that would make this a more viable solution.

Maybe then NodeOS could just use npm proper and supplement it with ndm:

npm install -g <package>
ndm <cmd> -g <package>

[piranna]

Yes @seanewest, that's just my idea, install services with NPM and manage them with NDM :-)

[seanewest]

ndm recently got an upgrade. Here's how things might look if we swapped npkg for npm+ndm:

Installing Packages

Global packages can be installed with the familiar npm install -g which installs directly to $HOME/lib/node_modules. I would think this could be pulled off by setting the node prefix to $HOME.

Service Management

ndm install PACKAGE

This will start and daemonize a service directly from a global or local package. Local packages live in the node_modules directory that you are in (or of a parent directory). Global packages are resolved under $HOME/lib/node_modules.

ndm comes with a bunch of other subcommands that allow you to manage these services:

ndm remove PACKAGE
ndm start PACKAGE
ndm stop PACKAGE
ndm restart PACKAGE
ndm list-scripts PACKAGE
ndm run-script PACKAGE

Programmatic API

Control services programmatically:

ndm = require('ndm')('PACKAGE');
ndm.install();
ndm.remove();
ndm.start();
ndm.stop();
ndm.restart();
//...

[bcoe]

@seanewest I feel like the biggest difference between ndm and npkg is ndm's requirement for a service.json.

I use the service.json for npm Enterprise, which consists of several services which work in conjunction -- a service.json makes sense for this use-case. Perhaps, for the simpler single-service-use-case, we could have ndm fall back to looking for fields in the package.json?

I think switching out npkg for ndm could potentially be a great way for us to pool our resources @groundwater.

[piranna]

Perhaps, for the simpler single-service-use-case, we could have ndm fall
back to looking for fields in the package.json?

+1

[bcoe]

npm/ndm#60

[piranna]

I've review the NDM code and its mechanism is really simple, just only creates scripts to be exec by system service daemon. NodeOS doesn't have any of them, only the API of init. I find it better to have an API that a bunch of System V init files :-P so maybe NDM could wrap the scripts creation mechanism in an object, and calling its methods internally create the scripts or call the NodeOS init API.

[bcoe]

@piranna, @rmg also suggested exposing service script generation as an API rather than simply templates.

[bcoe]

I've refactored ndm so that it will look for fields in a sevice.json file before looking for a package.json:

npm/ndm#62

Here's a library that's been updated to run with ndm:

https://github.com/bcoe/thumbd/blob/master/package.json

Essentially, you can now have the service stanza in your package.json, which works something like this:

{
  "name": "thumbd",
  "scripts": {
    "start": "node ./index.js"
  },
  "service": {
     "args": ["arg1", "arg2"],
     "env": {
          "PORT": {"description": "HTTP port", "default": "8000"},
          "USER_UID": "ubuntu"
      }
  }
}

• name is used for service name.
• scripts.start is used for the entry point of he service.
• service.args/service.env can be used to give hints about values the user must provide to run the service.

[piranna]

Shouldn't it be just the opposite, first look for service.json and if it's not found, looks for the service field?

[bcoe]

@piranna you're correct, I just had it reversed in the comment. It goes service.json which is useful for describing multiple-service dependencies, then package.json which makes sense for describing a single service.

[piranna]

You are welcome :-)