Skip to content
This repository has been archived by the owner on May 1, 2020. It is now read-only.

Support for multiple versions of purescript #50

Open
felixSchl opened this issue Jul 6, 2015 · 8 comments
Open

Support for multiple versions of purescript #50

felixSchl opened this issue Jul 6, 2015 · 8 comments

Comments

@felixSchl
Copy link

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
Copy link
Contributor

ethul commented Jul 6, 2015

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
Copy link
Author

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
Copy link
Contributor

ethul commented Jul 6, 2015

Agreed.

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

@ethul ethul self-assigned this Jul 7, 2015
@garyb
Copy link
Member

garyb commented Jul 7, 2015

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
Copy link
Contributor

ethul commented Jul 7, 2015

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
Copy link
Contributor

joneshf commented Jul 8, 2015

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

@ethul
Copy link
Contributor

ethul commented Jul 10, 2015

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
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants