Config

[groundwater]

Okay @EndangeredMassa let's talk config. I brought it up in #1 but want to give it a proper treatment here.

Modules that exposes services via a start script may need to start differently on different hosts. The clearest example is a webapp that requires a database connection. You cannot assume the database will exist at 127.0.0.1, it may be on another host or have a non-standard port. Heroku handles this by passing in configuration as environment variables.

I think the environment-variable style is good and familiar to people, so I'm going to keep using it. Init can easily handle this approach, you pass init a json stanza describing environment variables to pass to the child process. Easy! This also keeps init free from making assumptions about how packages should be run. In fact, init knows nothing about node modules at all. It's the npkg command that interprets the package.json file in a module, and turns that into a daemon.

I am fairly convinced that npkg is the right place to decide what environment variables to pass to init. I see two options here:

1. a command line option

   npkg start -e myapp.json webapp
   

2. a standardized location for config files (e.g. $HOME/etc/npkg/myapp.json) when running npkg start myapp.

There is a third option, which I do not think is the right way to go, which is to do some complicated logic to determine what environment variables to pass in. I'd rather not bake that logic into npkg, it should just blindly pass in environment variables.

defining environment variable config files

There are some environment variables I would like to standardize on passing into services, such as TMPDIR and VARDIR. Also, if a module requires an environment variable such as MYSQL_URL, we should start documenting those in package.json.

I would love for another tool to generate the default config, and to keep npkg free from dealing with config logic, but I'm also trying to make sure services are suuuuuper simple to install and run. I'm still debating what to do in my head, and am still undecided on option (1) or option (2).

[groundwater]

I think at the very least, a modules package.json should define what environment variables it expects, I propose either configs, envs, or environment as the key.

{
  "name" : "Myapp",
  "configs": {
    "LEVEL_DB_URL": "a level-db server"
  }
} 

The key in the above config stanza represents the name of the environment variable to pass in. The value of each entry is a description of what the variable should be.

Given a package.json file like this, a tool like npkg can prompt you whenever variables are missing, or even attempt to discover the values automatically.

[EndangeredMassa]

I would definitely go with option 2. I don't want to specify a config file location every time I start a service. It could be a useful override sometimes, but I think option 2 works better.

Being explicit about environment variable requirements is an interesting idea. You may want to consider a mechanism for specifying optional environment variables as well, but that may be too messy. I think it's fine to expand on package.json for some things, but I don't want to do it too often or too complexly.

[groundwater]

I think --environment -e FILE where the default value is $HOME/etc/npkg/$PKG.json. For example:

$ npkg start myapp

The above will load $HOME/etc/npkg/myapp.json, and tread that as a key-value mapping of environment variables.