Error when using `setup-haskell` as a library

[wenkokke]

When called, run in setup-haskell.ts reads the default values for its inputs from __dirname/../action.yml. However, __dirname is the absolute path of the directory containing the currently executing file, so when using this action as a library, that no longer resolves to the correct path. One of two things happens:

1. There is no action.yml file, and (presumably) the code exits with a file-not-found error.
2. There is an action.yml file, which does not contain the same keys.3.

If (2) happens, issue 121 becomes relevant. The type given to yamlInputs pretends that action.yml provides defaults for any possible string, and so when setup-haskell finds an action.yml file, it fails with:

Error: Cannot read properties of undefined (reading 'default')

Note that the defaults are read even when explicit values are provided.

There are a couple possible solutions:

1. Fix issue 121 and read the defaults in main.ts but not in setup-haskell.ts. That way the run function in setup-haskell.ts can be assigned a type that communicates that it requires a value for every input.
2. Don't read the defaults from action.yml. If it is too cumbersome to maintain the default values in two separate places, we could write a script that converts action.yml to action.json on each commit, which we can then import from setup-haskell.ts and bundle with the library. That way we can keep the defaults in one place without having to rely on __dirname.

The current workaround for this issue is to make sure an action.yml exists in __dirname which contains the default values for ghc-version, cabal-version, and stack-version.

[andreasabel]

Yes, I think the inputs should be organized as a record, not as a string-to-string map. From a maintenance perspective, I think generating this record from action.yml is attractive, as then files cannot get out of sync. This repo already has some pre-commit magic that could include the generation of action.json. But maybe one could start modest and just refactor the run() method to take a record of inputs rather than the map. @wenkokke : Are you available and would you want to make a stab at this?

[wenkokke]

I'm currently generating the record description from action.yml for setup-agda, so there's a decent amount of code that could simply be copied over.

[hazelweakly]

The record generation would be the better way to do this, I agree. I never fully fleshed out the idea of this as a library and I'm afraid some of the warts are very much a consequence of that.

The run function probably should also be a bit better designed as well; it was originally just a stateful entrypoint and it was "librarified" by way of just dumping the entry point into a separate function

[wenkokke]

I get that. Just did the rewrite away from that for setup-agda.