Emanate should provide a way to run some scripts on use

[kayila]

Emanate is a great script for 'moving in' to a system, but some of my files require other things to be done (for instance things cloned, etc.) Emanate should provide a way to have a set of 'setup scripts' to run in order to set things up.

[duckinator]

So, rough idea for this:

1. Scripts would be Python modules, located in ./scripts/.
2. Scripts would be run in alphanumeric sort order. The easiest way to guarantee the order would be to number them.
3. Emanate would have a run_module(script_path, clean_or_create) function somewhere.
   • script_path = path to the script,
   • clean_or_create = either "clean" or "create", depending on which mode emanate is in.
   • This ultimately calls main(clean_or_create) in the Python module.
4. There would be an emanate run-module <module name> <clean_or_create> alias.

Some notes:

• My reasoning for using modules instead of independent scripts is that it means we can more tightly integrate things later, e.g. by adding helper functions similar.
• Some of those helper functions would be things like "download this file and save it to this path", "download this file to a temporary directory", "download this .zip file and extract it to this location", "clone this git repo", "mark this file as executable", etc.

Would that work for you, @kayila?

[duckinator]

Actually, instead of main(), I think a better way would be to have separate clean() and create().

With main() the boilerplate code is:

def main(clean_or_create):
    if clean_or_create == "create":
        create()
    else:
        clean()

def create():
    pass

def clean():
    pass

Whereas with the latter, you lose the main() being duplicated in every script, leaving:

def create():
    pass

def clean():
    pass

[nbraud]

Not sure I'm super keen on having code-execution capabilities bolted into emanate.

If you are doing it, this seems like a reasonable plan, though I would put some caveats:

• scripts is a super-generic folder name, and using it means that emanate cannot be used to manage a (toplevel) directory with that name; perhaps use emanate_scripts, .emanate_scripts, or somesuch;
• emanate should likely fix specify the locale in which the scripts are sorted (say, C.UTF-8).

(@duckinator asked for my opinion)

[duckinator]

Thinking about it more, I'm leaning towards something far more straightforward -- the ability to execute commands at 4 points of Emanate's normal execution, specified like so:

{
  "ignore": ["README.md", "emanate.pyz"],
  "before-create": "./emanate-scripts/before-create.sh",
  "after-create": "./emanate-scripts/after-create.sh",
  "before-clean": "./emanate-scripts/before-clean.sh",
  "after-clean": "./emanate-scripts/after-clean.sh"
}

They'd each stop the entire process if they exited with a non-zero status code.

And possibly (if there's interest), we could also create a basic script management tool similar to what I described above, and you could just have various invocations of that as the specified commands to run.

[duckinator]

@nbraud what're your thoughts on that approach^?

[nbraud]

That seems OKish. Maybe add a way to turn script support off, that can't be overriden from within the source directory (for instance with an src/emanate.json file)

[duckinator]

Could perhaps have a no-scripts option and prioritize it like so:

1. Command-line flag. (--no-scripts)
2. A global configuration file. (~/.config/emanate.json or Windows/macOS equivalent as appropriate.)
3. The JSON file in the source directory (same option as ~/.config/emanate.json, different file)

[nbraud]

Makes sense; might get awkward with the current config infrastructure, if the priority order for that option is different from everything else (ordering the global config before the local one), but I don't see a clean way out of this.

Maybe erroring-out if the scripts option is set in the source dir's config file, since it's kind-of meaningless there? (A user who wants not to run scripts in that repo can just make sure not to have a scripts directory, and an attacker who has the ability to add scripts to the repo can presumably edit the config file in there too)