protolude 0.1.6: fix ambiguous occurrences

[ilovezfs]

Prevent PureScript build failure with protolude 0.1.6 due to
ambiguous occurrence errors arising from the following conflicts:

Protolude.fromStrict vs. Data.ByteString.Lazy.fromStrict
Protolude.decodeUtf8 vs. Data.Text.Lazy.Encoding.decodeUtf8
Protolude.encodeUtf8 vs. Data.Text.Lazy.Encoding.encodeUtf8

In order to preserve the ability to use "fromStrict" without qualifying
it (e.g., Z.fromStrict), this fixes the ambiguous occurrences in a way
that is backwards incompatible with protolude 0.1.5. In particular,
using fromStrict without qualification requires hiding it, but since
protolude 0.1.5 doesn't actually export fromStrict, importing 0.1.5
hiding fromStrict will trigger a dodgy imports warning.

Bumping the protolude dependency to >= 0.1.6 requires bumps to
PureScript's designated Stack LTS and Nightly resolvers. Switching to
lts-6.7 and nightly-2016-07-19 requires a few unrelated fixes:

System.FilePath: remove redundant imports (-Wunused-imports)
parseURL: replace with non-deprecated parseRequest (-Wdeprecations)
fromJust: import from Data.Maybe instead of Unsafe (prevents error)

Also set protolude >=0.1.6 and http-client >= 0.4.30 (for parseRequest)
in purescript.cabal, and update the CONTRIBUTORS file.

[paf31]

Is this causing a build to break?

Also, could you please update CONTRIBUTORS.md?

[ilovezfs]

Yes, GHC 8.0.1

src/Language/PureScript/Ide/Pursuit.hs:56:32: error:
    Ambiguous occurrence ‘fromStrict’
    It could refer to either ‘Protolude.fromStrict’,
                             imported from ‘Protolude’ at src/Language/PureScript/Ide/Pursuit.hs:22:1-26
                             (and originally defined in ‘Data.Text.Lazy’)
                          or ‘Data.ByteString.Lazy.fromStrict’,
                             imported from ‘Data.ByteString.Lazy’ at src/Language/PureScript/Ide/Pursuit.hs:26:49-58

src/Language/PureScript/Ide/Pursuit.hs:68:30: error:
    Ambiguous occurrence ‘fromStrict’
    It could refer to either ‘Protolude.fromStrict’,
                             imported from ‘Protolude’ at src/Language/PureScript/Ide/Pursuit.hs:22:1-26
                             (and originally defined in ‘Data.Text.Lazy’)
                          or ‘Data.ByteString.Lazy.fromStrict’,
                             imported from ‘Data.ByteString.Lazy’ at src/Language/PureScript/Ide/Pursuit.hs:26:49-58

etc.

[ilovezfs]

I'll update contributors in a bit, since that will change the checksum of the PR patch link in Homebrew/homebrew-core#2905

[paf31]

since that will change the checksum of the PR patch link

I can merge it as two separate commits.

[ilovezfs]

@paf31 PR refreshed.

[kritzcreek]

Sorry, looks like this happened because of protolude 0.1.5 -> 0.1.6. Should've maybe been more conservative with the bounds...

[ilovezfs]

@kritzcreek Yes, that's why. Note the 🍏 for Travis now with nightly-2016-07-11 and lts-6.7

[kritzcreek]

Ahh so CI didn't catch it, because you compile PS with a newer snapshot than the one our CI used. Allright I get it.

EDIT: Does that mean we need a protolude > 0.1.5 bound in the cabal file now?

[ilovezfs]

No, actually we compile with straight up cabal, no Stack involved. But when I realized that the problem was 0.1.5, I figured I'd try bumping your LTS and Nightly for Stack, which led to some warnings failures and a hard error for fromJust. The bounds in purescript.cabal should also be bumped a bit too, I suppose.

[ilovezfs]

EDIT: Does that mean we need a protolude > 0.1.5 bound in the cabal file now?

Yup.

[ilovezfs]

@paf31 @kritzcreek PR refreshed.

[kritzcreek]

👍 thanks!

[ilovezfs]

Did something change to prevent the cc-osx-lts-sdist failure on Travis?

[kritzcreek]

@ilovezfs the osx instances are a bit flaky. What a great commit message!

[ilovezfs]

What a great commit message!

Thanks :)

[phadej]

parseURL to parseRequest requires adding http-client >= 0.4.30 which defines it in the first place. Otherwise if older http-client is picked, the build will fail as well. (http-pipes re-exports http-client's Network.HTTP.Client)

[ilovezfs]

@phadej Thanks for catching that. It should be fixed now.

[paf31]

Does this add any new dependencies? We might need to rerun the license generator.

[ilovezfs]

None I know of, since http-client is already in the license file.

[paf31]

Thanks!

[ilovezfs]

Cool, thanks @paf31!