Add 'only_once' action block or 'requires' parameter to actions

[JakobGM]

It would be nice to be able to specify actions that only need to be executed once, and never again. Something along the lines of:

module/neovim:
  only_once:
    run:
      shell: pacman -S neovim

  on_startup:
    compile:
      source: init.vim
      target: $XDG_CONFIG_HOME/nvim/init.vim

We could save the actions that have been run in $XDG_DATA_DIR/astrality/only_once.xxx, perhaps even use this pypi module. If we end up using that package (unecessary extra dependency?), we could also replace all $XDG_CONFIG_HOME logic in the rest of the stack.

The difficulty would be to decide on a practical data format. Then load that data format and compare only_once actions to items in that file. Perhaps use hashes? And/or datestamp each entry in the file?

Alternatively, we could add requires parameters to all action types, which would provide the same capabilities. That would be super easy to implement, as we could reuse the logic in astrality.requirements.Requirement. Estimated time cost: 10 minutes of implementation, 1 hour of testing.

This would result in something like:

module/neovim:
  on_startup:
    run:
      - shell: pacman -S neovim
        requires:
          installed: '!neovim'
    compile:
      source: init.vim
      target: $XDG_CONFIG_HOME/nvim/init.vim

The ! negates the requirement, and must be implemented (should not be too difficult).

[sshashank124]

One catch specifically for the - shell: pacman -S neovim line would be that the line would require elevated permissions to run. This could either be done through some sort of PolicyKit/DBus implementation in python, or alternatively would require running the astrality process with sudo or some root user. The problem with the second one being that any files generated by the elevated astrality process would then by owned by the root user instead of the user running the program.

[JakobGM]

Requiring a subset of users to run Astrality with sudo steals a lot of safety control away from the user, so I think we should avoid that.

To be honest, I have absolutely no knowledge of PolicyKit/DBus, but I will take a look at its feasability. We could add another CLI flag --sudo-password=my_password, and use that whenever an action sets the parameter sudo: true. Or we could just check the presence of 'sudo' in run actions, then pass the password in to the subprocess. Here is an example solution.

Looking for 'sudo' in run actions is probably the most natural, but it will only work for shell actions, not compile and import_context.

What do you think about only_once vs. specific action requires parameters?