628 added a script we can run to fetch all supported versions of the purs executable.
This PR adds the Registry.App.CLI.PursVersions module, which can be used to call that script within the registry codebase.
Errors are handled in the following way:
An error that occurs calling purs-versions is thrown
An error is thrown with all output of purs-version which fail to parse
An error is thrown if the output of purs-versions is empty
I've added a test that makes sure the output of this utility matches what we expect it to be.
This means that when a new compiler version is released and purescript-overlay is updated, registry things will start failing until the new version is added to the snapshot. I've discussed this with @thomashoneyman and we think that behavior is desired, as it allows us to make sure we are supporting the full set of compiler versions we expect, without having to hard code them anywhere in registry app code.
To support https://github.com/purescript/registry-dev/issues/255 we need to know the full list of compilers that the registry supports.
628 added a script we can run to fetch all supported versions of the
pursexecutable.This PR adds the
Registry.App.CLI.PursVersionsmodule, which can be used to call that script within the registry codebase.Errors are handled in the following way:
purs-versionsis thrownpurs-versionwhich fail to parsepurs-versionsis emptyI've added a test that makes sure the output of this utility matches what we expect it to be. This means that when a new compiler version is released and
purescript-overlayis updated, registry things will start failing until the new version is added to the snapshot. I've discussed this with @thomashoneyman and we think that behavior is desired, as it allows us to make sure we are supporting the full set of compiler versions we expect, without having to hard code them anywhere in registry app code.