support for different dist operations

[rsgalloway]

some services like systemd are very finicky about file names and links, and will not work with distman symlinks, for example this will not work with systemd:

/etc/systemd/system/app.service -> versions/app.service.0.abc123

because the link target is named app.service.0.abc123 (it has to send in .service).

how to handle this?

• option 1: support different dist operations, like copy, hardlnk, etc
• option 2: dist a folder, and link into the folder:

        "services": {
            "source": "services",
            "destination": "{DEPLOY_ROOT}/services",
            "new directive here": {..}
        },

so that it would create:

/etc/systemd/system/myapp.service -> ${DEPLOY_ROOT}/versions/services.0.abc123/myapp.service

this could potentially depend on #55

[rsgalloway]

for option 2 above, here is an example dist target, that would depend on a post-dist pipeline step from #55 to link into the versioned folder:

"services": {
  "source": "services",
  "destination": "{DEPLOY_ROOT}/services",
  "post": {
    "link": {
      "script": ["ln -s {DEPLOY_ROOT}/services/myapp.service /etc/systemd/system/myapp.service"]
    }
  }
}

i.e.

/etc/systemd/system/myapp.service -> ${DEPLOY_ROOT}/services/myapp.service

where ${DEPLOY_ROOT}/services is itself a link to a versioned folder that distman creates when disting the target. the post-dist "link" step would link into that folder, so the systemd link would actually be two levels deep (not sure if systemd would complain about that too).

to make this work, we would need #55 and also resolving env vars like DEPLOY_ROOT in the pipeline steps.

[rsgalloway]

another reason to support different dist operations (copy or hardlink) is because windows does not always support symlinks.