search

purescript-deprecated / gulp-purescript

Gulp plugin providing PureScript compiler tasks
34 stars 8 forks source link

Support for multiple versions of purescript #50

Open felixSchl opened 9 years ago

felixSchl commented 9 years ago

As per your README:

This plugin requires that the PureScript binaries first be installed. The binaries may be installed using the purescript NPM package or as described on the PureScript installation section of the GitHub wiki.

This has the disadvantage that projects are dependent on a command in their PATH called psc etc that happens to be purescript and happens to be at a specific version. Seeing that purescript is on npm, would it not be feasible to tell gulp-purescript either the semver of purescript to use, or provide a path to the binary? I do understand that their is a certain degree of coupling between gulp-purescript and the actual purescript version - i.e. commands are added / renamed / removed. But if we added this now, at least for the future we could choose to stick with an older version of purescript and gulp-purescript if a project maintainer chose to.

ethul commented 9 years ago

It's true that gulp-purescript will default to a command called psc that is present on the user's PATH. However, by installing the purescript npm package, gulp-purescript will detect that it is installed and use the binaries from the package over what is on the user's PATH.

I wonder if taking the approach of installing the purescript npm package at one's desired purescript version, and then installing a compatible version of gulp-purescript, will satisfy your use-case.

felixSchl commented 9 years ago

I would say so, given that the module can be installed locally, i.e. a project can specifiy the purescript versions that are capable of building it.

ethul commented 9 years ago

Agreed.

Are there any changes necessary? For example, should we add documentation to describe this scenario further?

garyb commented 9 years ago

I guess we could add a feature that allows specifying a version range by reading a field from the project's package.json and then parsing psc --version's output... but probably using the purescript package is a more sensible way!

ethul commented 9 years ago

I agree that using the purescript package is probably the easiest approach.

We could add a compatibility table to the readme or have gulp-purescript issue an error message recommending a version to install if it detects a compatibility mismatch. I suppose we will have to make sure to back-port bug fixes to the stable gulp-purescript branches as applicable (currently we just have 0.4-stable).

joneshf commented 9 years ago

It seems like this might be a use case for peerDependencies.

ethul commented 9 years ago

I agree that the idea of peerDependencies is what we are after.

However, my hesitation is that I don't know if we can assume the user wants to install the purescript NPM package. For instance, they could just have an old version of purescript on their system and want to use that. If we add a peerDependencies entry of the purescript NPM package, then we would force an override of their system binaries installed along with the package.

Not sure if this is a bad thing. It might actually be the best approach to ensure proper version compatibility. Also, if the user is on npm@3, having the peer dependency is even better because it does not force installing anything. It will just give a warning.

I am open to discussing this further and hearing others' thoughts on this approach.

damncabbage commented 7 years ago

Necro'ing a thread here, but in case someone else reads this:

However, my hesitation is that I don't know if we can assume the user wants to install the purescript NPM package.

Good call. Said package doesn't work on CentOS 6, for example, and wouldn't work with testing a new (unreleased) version of PureScript; it really can't be assumed that people can use the purescript npm package without a way to work around it.