RFC: depend on the PureScript compiler

[f-f]

Following up from this Discourse thread, a big problem seems to be that when we have breaking changes in the compiler there are "ecosystem splits", and picking the right packages is hard (especially with bower) if the people just does npm install purescript (from personal experience, the 0.12 transition was indeed quite bad).

Spago is currently not immune to this problem: we're wrapping whatever compiler the user has installed, so if we have a post-0.12 package set, it's not gonna work if the user has purs-0.11 installed. In general, the "compiler version the package-set is compatible with" is not checked against "compiler version currently installed", and this is not right! (as it's easy to diverge)

As usual, the "Stack solution" for this is really good:

• every LTS has a compiler version associated with it
• stack installs a sandboxed version of the compiler for every project

The downside of this is that the tooling (read: editor integrations) will have to talk to spago instead of the compiler for things like purs ide.

In our case we would not download a version of the compiler, but we could:

• we'd depend on the compiler library, and run things through it instead of calling an external executable
• this means that a certain Spago version would have an associated Purs version (i.e. not dependent on the package-set)
• editor plugins should call stuff like spago ide instead of purs ide

[justinwoo]

you wouldn't need to make some spago ide, editor plugins already largely prefer to call project path purs and people use different versions of the purescript compiler already.

[JordanMartinez]

In general, the "compiler version the package-set is compatible with" is not checked against "compiler version currently installed", and this is not right! (as it's easy to diverge)

Why go to the extent of including the compiler itself? One solution to this problem could be to just specify which version of the compiler with which a package set is compatible and verify that the correct compiler version is being used when building the project. I'm guessing the Stack solution improves the user interface in that one does not need to change one's compiler version before building a project. If so, doesn't this push the need to 'change compiler versions' upstream though, so that one now needs to change "spago versions" in order to use the correct compiler/package-set to build a project?

In short, I don't fully understand the tradeoffs here. What gains does one get through this approach and at what costs?

[f-f]

@JordanMartinez good questions.

In the end, my main goal here is the following:

ensure that a package-set is tied to a specific compiler version (exactly as they do in Stackage).

Now, shortly after writing down this issue I realized that baking the compiler into Spago is not a good idea. Because this means tying the Spago version to a Purs version, and this implies some uncomfortable things like:

• cannot get new Spago features on old versions of the compiler
• having a new Spago release with every new compiler version
• etc

So, what we should really do is to make package-sets aware of the compiler version they should be run in. This happens already with purescript/package-sets, where the minimum compiler version is stated in the release name itself. I think this would be a good solution for Spacchetti.

Then, we should check that we're running at least that compiler version in spago (by running purs --version every time we run install), and failing with a suggestion for the user if that's not right, so they can install the right version (note: we'll have to take care of things like upgrading minor versions but not majors).

This would be already enough to have decent assurance and prevent you from running broken packages.

Now, the Stack approach goes even further, as Stack will download the right compiler version for you. It'd be nice, but it would imply some amount of work that we can skip for now.

[JordanMartinez]

So, what we should really do is to make package-sets aware of the compiler version they should be run in. This happens already with purescript/package-sets, where the minimum compiler version is stated in the release name itself. I think this would be a good solution for Spacchetti.

I agree.

Now, the Stack approach goes even further, as Stack will download the right compiler version for you. It'd be nice, but it would imply some amount of work that we can skip for now.

That sounds like a good long-term feature to implement eventually since it's not quite a pain point that needs to be addressed in this current context.

[f-f]

Cool, since all of this makes sense I'll close it in favor of spacchetti/spacchetti#63 and #101