Add a way to override the default version of a tool

[maxdeviant]

This idea came to me while reading through purescript/purescript#3942, specifically the part about updating CI to use the v0.14.0-rc2 tag:

• Update .travis.yml to grab the most recent RC (see eg purescript/purescript-prelude@268870d)

Thinking about how this would map onto GitHub Actions, the obvious thing to do would be to go through all of the purescript-contrib libraries and update their ci.yml files to point to a specific tag:

steps:
  - uses: actions/checkout@v2
  - uses: purescript-contrib/setup-purescript@main
    with:
      purescript: "0.14.0-rc2"
  - run: spago build

However, doing it this way seems like it would cause headaches if we get into the situation where a future release candidate is needed, as we would then have to go through all the libraries again to update the tag.

As an alternative solution, I'd like to propose creating a new branch (purescript-0.14, for example) for the PureScript v0.14.0 release. On this branch we'd reference whatever the latest v0.14.0 tag is as the default instead of latest.

We can then update all of the purescript-contrib libraries to point to our separate branch:

steps:
  - uses: actions/checkout@v2
  - uses: purescript-contrib/[email protected]
  - run: spago build

This way if we did end up having to go through multiple release candidates we could just bump the version of PureScript referenced on the purescript-0.14 branch and all of the projects referencing that branch would then pull the correct version.

In order to accomplish this it seems like we would need to add a way to override the default version of a tool that should be used if one is not provided by the consumer of the Action.

[thomashoneyman]

If this is just a short-term solution, then we can just hardcode the compiler version into the branch, so anyone on the purescript-0.14 branch is going to get the latest of the 0.14 series and compatible tooling no matter what they provide as input to the action.yml file.

As a longer-term solution we do have other options. For example, we could add "latest-unstable" in addition to "latest" which pulls in the release candidates, so folks could use that downstream. We could also add support to setup-purescript for SemVer ranges, so you could do something like purescript: "0.14.x" to pull in the latest of anything in the 0.14 series. I believe either of those would get you the solution you're looking for and would be usable for future compiler releases, too.

Curious to hear what you think of both the short-term and long-term solutions available to us.

[maxdeviant]

I think I would definitely gravitate towards a long-term solution, as I think we'd have to go through this process with every new release of the PureScript compiler.

Personally, my preference would be introducing a latest-unstable, as that seems more straightforward than SemVer ranges.

Does latest-unstable work the same way as latest? If I go to https://github.com/purescript/purescript/releases/latest I am automatically redirected to the latest release (https://github.com/purescript/purescript/releases/tag/v0.13.8). However, going to https://github.com/purescript/purescript/releases/latest-unstable 404s. I'm guessing if we pursue that route we would need to start using the GitHub API rather than GitHub URLs.

[thomashoneyman]

When the user supplies "latest" as their desired version for a tool, we look it up in the versions.json file (https://github.com/purescript-contrib/setup-purescript/blob/main/dist/versions.json). We do that rather than hit the GitHub API because otherwise we get rate limited by GitHub like one out of every 10 builds with setup-purescript. So I'd like to avoid using the API if we can.

The versions.json file is really simple at the moment: it's just a mapping of a tool to its latest release. We could expand the file to be a mapping of a tool to its latest stable & unstable release, or go all-in and have the file contain a mapping of a tool to all its valid releases. That would also allow us to be smarter about things like version ranges, because we'd have all available versions already stored.

The file is managed by the UpdateVersions module:

• https://github.com/purescript-contrib/setup-purescript/blob/main/src/Setup/UpdateVersions.purs

and gets executed once per day:

• https://github.com/purescript-contrib/setup-purescript/blob/main/.github/workflows/sync.yml

to update the versions.json file with the latest information.