Feature: package.install provider: luarocks

[airtonix]

Description

currently to get my awesomewm setup i need to install a bunch of lua packages. and comtrya doesn't seem to want to let me do this:

  - action: command.run
    where: os.name == "linux"
    sudo: true
    command: sh
    args:
      -  -s
      - |
        echo "installing luarocks packages";
        
        packages=(path luafilesystem power_widget lgi lcpz/awesome-freedesktop awesome-autostart lyaml)
        
        for package in $packages; do 
          echo "installing ${package}"
          luarocks install $package
        done

so i have to do this:

  - action: command.run
    where: os.name == "linux"
    sudo: true
    command: luarocks
    args: 
      - install
      - path
  - action: command.run
    where: os.name == "linux"
    sudo: true
    command: luarocks
    args: 
      - install
      - luafilesystem
  - action: command.run
    where: os.name == "linux"
    sudo: true
    command: luarocks
    args: 
      - install
      - power_widget 
  - action: command.run
    where: os.name == "linux"
    sudo: true
    command: luarocks
    args: 
      - install
      - lgi 
  - action: command.run
    where: os.name == "linux"
    sudo: true
    command: luarocks
    args: 
      - install
      - lcpz/awesome-freedesktop
  - action: command.run
    where: os.name == "linux"
    sudo: true
    command: luarocks
    args: 
      - install
      - awesome-autostart 
  - action: command.run
    where: os.name == "linux"
    sudo: true
    command: luarocks
    args: 
      - install
      - lyamledg

it'd be great if all I had to do was this:

  - action: package.install
    provider: luarocks
    where: os.name == "linux"
    list: 
      - path
      - luafilesystem
      - power_widget
      - lgi
      - lcpz/awesome-freedesktop
      - awesome-autostart
      - lyaml

Additional information
Add more context which didn't fit in the fields above.

[martintc]

I have a PR opened for this. If you don't mind testing it and letting me know if that is sufficient! Sorry for not getting around to this a month after you filed this issue.

[airtonix]

@martintc no problemo.

I'm a filthy frontend developer peasant, so I'm not familiar with the correct goats i need to sacrifice in order to test out this branch/pr.

Any pointers?

[martintc]

@martintc no problemo.

I'm a filthy frontend developer peasant, so I'm not familiar with the correct goats i need to sacrifice in order to test out this branch/pr.

Any pointers?

Should be able to clone the repo. I usually clone the main github one and add my repo as a separate remote with git remote add martintc [email protected]:martintc/comtrya.git. From there, if you have the openssl development libraries installed, that should do it. Occasionally you may get some weird perl error, may have to install perl or some perl package. Saw you opened an issue on fedora, for openssl there should be an openssl-devel package.

[martintc]

Talking with @icepuma, implementing language specific package managers is a road we don't really want to go down and want to keep the scope of package providers limited to system wide (i.e. win-get, scoop, brew, apt, pkg, dnf, etc). This can lead us down a slippery slope of writing package providers for cargo, npm, and as more languages get created, they all seem to be employing their own package managers. We think the best solution for using package managers associated with languages is best handled right now via command.run as you already do for luarocks.

[rawkode]

OK. I think we can work around this.

@airtonix, sorry sh -s doesn't work as expected with cmd.run.

First, we can support cmd.script and allow more complex args.

@martintc Great initiative adding a luarocks provider, but I do agree with @icepuma that we don't want to start adding every binary or package manager to the core Comtrya project; but that doesn't mean we shouldn't try to support them.

Comtrya does something really well: atoms. We provide building blocks to execute any command on any system.

Presently, we support actions (in-core) to abstract away the individual steps and details of performing common actions.

So why don't we provide a higher level abstraction for end-users?

Please excuse the name, it needs thought about properly.

compounds:
  - cargo:
      plan: ls ${CARGO_HOME}/.bin
      single: cargo install ${_1}
      list: cargo install ${_N}

  - luarocks:
      plan: luarocks list | rg ${_1}
      single: luarocks install ${_1}
      list: for rock in ${_N}; do luarocks install ${rock}; done

These could be defined by individual users, or shared via some Comtrya Hub.

This would enable:

- action: compound.luarocks
  where: os.name == "linux"
  name: power_widget
- action: compound.luarocks
  where: os.name == "linux"
  name: lgi

or

- action: compound.luarocks
  where: os.name == "linux"
  list: 
    - path
    - luafilesystem
    - power_widget
    - lgi
    - lcpz/awesome-freedesktop
    - awesome-autostart
    - lyaml

[martintc]

OK. I think we can work around this.

@airtonix, sorry sh -s doesn't work as expected with cmd.run.

First, we can support cmd.script and allow more complex args.

@martintc Great initiative adding a luarocks provider, but I do agree with @icepuma that we don't want to start adding every binary or package manager to the core Comtrya project; but that doesn't mean we shouldn't try to support them.

Comtrya does something really well: atoms. We provide building blocks to execute any command on any system.

Presently, we support actions (in-core) to abstract away the individual steps and details of performing common actions.

So why don't we provide a higher level abstraction for end-users?

Please excuse the name, it needs thought about properly.

compounds:

  - cargo:

      plan: ls ${CARGO_HOME}/.bin

      single: cargo install ${_1}

      list: cargo install ${_N}



  - luarocks:

      plan: luarocks list | rg ${_1}

      single: luarocks install ${_1}

      list: for rock in ${_N}; do luarocks install ${rock}; done

These could be defined by individual users, or shared via some Comtrya Hub.

This would enable:

- action: compound.luarocks

  where: os.name == "linux"

  name: power_widget

- action: compound.luarocks

  where: os.name == "linux"

  name: lgi

or

- action: compound.luarocks

  where: os.name == "linux"

  list: 

    - path

    - luafilesystem

    - power_widget

    - lgi

    - lcpz/awesome-freedesktop

    - awesome-autostart

    - lyaml

In case you don't see it on the discord. Last night I was playing around with a similar/exact idea, my spit balling is in the comtrya channel. Allow users to specify modules as an abstraction in yaml and behind the scenes, comtrya resolves it via command.run

A sample of what I had in mind.

# modules.yaml
define_module:
  name: systemd
  define_actions:
    - name: start
      parameters:
        - service_name
      command: systemctl start ${service_name}
      sudo: true
    - name: reload
      command: systemctl daemon-reload
      sudo: true
    - name: enable
      parameters:
        - service_name
      command: systemctl enable ${service_name}
      sudo: true

# systemd.yaml
actions:
  - action: systemd.reload
  - action: systemd.start
    service_name:
      - nginx
      - sshd
  - action: systemd.enable
    service_name:
      - nginx
      - sshd
      - firewalld

With a way of getting modules via git.