feat: add extra_packages input

[mrcjkb]

Fixes #35.

[mrcjkb]

I hate Bash!

[mrcjkb]

It works!

[teto]

I dont think this covers enough cases:

• what if the software isn't in nixpkgs
• what if I want an override for it
• what if I dont know nix ?

I think it's best to let the users in control of the setup, can't they install packages with a pre: step thing ?

[mrcjkb]

I dont think this covers enough cases:

* what if the software isn't in nixpkgs

I don't think it would be feasible to try to cover all edge cases with this workflow.
This is a simple way to add basic support for external build dependencies.

* what if I want an override for it

* what if I dont know nix ?

Users shouldn't need to know nix or write package overrides. All this input does is add the package to the PATH so it can be used by make. No nix involved.
If a plugin needs an override to build for some reason, it should probably be done in a custom workflow. The script is available as a luarocks package, so it can be installed in custom workflows.

I think it's best to let the users in control of the setup, can't they install packages with a pre: step thing ?

If this were a JavaScript action, it would be possible to install packages using other github actions dedicated to installing them. I'm pretty sure there are far less github actions for installing packages than there are packages available on nixpkgs.

[teto]

Users shouldn't need to know nix or write package overrides. All this input does is add the package to the PATH so it can be used by make. No nix involved.

User must use the derivation path used by nix. Granted there is https://search.nixos.org/packages?channel=unstable&size=50&sort=relevance&type=packages&query=neovim

I don't think it would be feasible to try to cover all edge cases with this workflow.

depending on how much it covers is it worth adding ?

Right now users do something like

  luarocks-upload:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: nvim-neorocks/luarocks-tag-release@fix-treesitter
        env:
          LUAROCKS_API_KEY: ${{ secrets.LUAROCKS_API_KEY }}
        with:
          name: nvim-treesitter-test
          version: 0.1
          license: apache 2
          detailed_description: |
            The goal of nvim-treesitter is both to provide a simple and easy way to use the interface for tree-sitter in Neovim
            and to provide some basic functionality such as highlighting based on it.
          build_type: "make"
          template: nvim-treesitter-luarocks.template

Our action runs in docker if I trust action.yaml:

  using: "docker"
  image: "Dockerfile"

is there a way to have it run on the host instead ? so that users can install dependencies on the host of their choice (ubuntu/fedora etc) then run this action which can use the previously installed software in PATH. We would need to install nix on that host though.

Installing software is hard (only nix does it well IMO) so adding an action-specific way of doing it will end up being a lot of work + confusion for plugin authors IMO.

[mrcjkb]

User must use the derivation path used by nix.

What do you mean by derivation path? The nix store path or the nixpkgs attribute set path, e.g. lua51Packages.dkjson?

is there a way to have it run on the host instead ?

We could try out a composite action that uses cachix/install-nix-action.
I initially wanted to avoid depending on other github actions, but if we can hide the dependency implementation from users (so they don't have add the install-nix-action to their workflow files), maybe it's a good idea.

[mrcjkb]

Alternate approach in #38

[mrcjkb]

Closing in favour of #38