spago
spago copied to clipboard
purescript
Can not publish when compiler version is not available
Before on the registry github https://github.com/purescript/registry/issues it was possible to specify a compiler version. I didn't see such a configuration available here https://github.com/purescript/spago#the-configuration-file
I get this error
2023-10-08T13:27:55.995Z Compilation failed because the build plan compiler version 0.15.12 is not supported. Please try again with a different compiler.
❌ Registry finished processing the package, but it failed. Please fix it and try again.
How do i set the compiler version to 0.15.10 ?
@flip111 since you opened so many issues for various things, some of which are likely easy to fix, do you plan on contributing those fixes?
I'll take that as a no.
@f-f how much of the publish pipeline uses the locally-installed purs binary, and how much of it is just setting up the needed stuff for the Registry to handle it?
We necessarily have to use the local compiler to ensure that the package can indeed compile before submitting it to the registry (the registry pipeline will try to compile it, so we might as well fail locally instead of waiting for that). The pipeline will also want to know which version of the compiler to use to do this compilation.
So I guess the answer is "we use it quite a lot":
- we compile first to see if the project compiles at all
- we come up with a build plan using the solver, and then do another compilation with this new build plan
- we get the graph and run the pedantic-packages check so that dependencies are necessarily correct
- we pass the current version of the compiler to the registry pipeline to do its compilation
The error in this report is coming up because the local purescript version was not yet supported by the registry pipeline. One can go around that by downgrading the local version, but I don't think that's an acceptable solution - if we have published a compiler then we ought to support it throughout our infrastructure.
I think the proper fix for this would be to make sure that on every release of the compiler we'd also automatically update the registry to support the new release - this would entail automatically pushing patches like this one
cc @thomashoneyman
Ideally the PureScript compiler release process would include updating purescript-overlay and the registry. The overlay auto-updates every day and can be manually updated by running the daily-update action or manually running the generate script and committing the result. The registry can then be updated with a nix flake update (or by manually setting the purescript-overlay flake dependency to the latest commit).
spago upgrade also does not work, probably for the same reason
» npx spago upgrade
Reading Spago workspace configuration...
Read the package set from the registry
✅ Selecting package to build: foldable-traversable-extra
❌ No package set found for the current compiler version.
@thomashoneyman would it make sense if the compiler had its own Nix scaffolding so we wouldn't have to update an extra repo? (we'd still need to update the Registry CI)
@thomashoneyman would it make sense if the compiler had its own Nix scaffolding so we wouldn't have to update an extra repo? (we'd still need to update the Registry CI)
We need to support a range of compiler versions so pointing at the compiler repo is unsuitable, unfortunately. I also doubt the compiler team wants to support a Nix build (in purescript-overlay I'm just exposing the binary, not a full build).
I'm certainly happy to move purescript-overlay to be owned by the core team, but I haven't done so simply because it includes tools like purs-tidy and purescript-optimizer which aren't core, but which almost every project should have access to.
I also doubt the compiler team wants to support a Nix build
The core team and the compiler team have very much overlap, so I'd say that if the Registry - in its role of packaging infrastructure - relies on a Nix build to use the compiler, then it's fair to say that Nix build needs to be supported by someone in core.
I see virtually no difference between "the compiler repo contains a bunch of Nix code" and "there's an external repo that is updated on release" - in both cases if it breaks then the release manager has to fix it. There is an advantage in having it in the repo, which is that we can version that code together with the rest, which is less bureaucratic.