lens-3.6 test fails to compile about stackage

[snoyberg]

Which version of GHC and containers are you using?

[ekmett]

I think this is due to the fact that the doctest suite for lens doesn't name containers explicitly as a dependency, so if you have containers 0.5 installed it will use the system one and not the one used by the package. @JohnW reported the same issue just now.

I've pushed lens 3.6.0.1 backporting a fix that was in 3.7 (due to be released next week) for this issue.

If this isn't the issue I may have to work with Simon and the other doctest guys to resolve it.

[ekmett]

Simon is still having the issue. I'll need to dig in deeper.

[sol]

It's a different issue. The properties test suite won't complete sometimes.

[ekmett]

Ah. I've disabled the expectedFailure properties, and pushed a 3.6.0.2. That should address Simon's issue at least.

I added a few more explicit dependencies to the doctest harness. I can no longer duplicate Bart's issue locally.

[stillyetanothergithubuser]

@ekmett I wish I'd reported it, but I think youve got the wrong johnw.

[ekmett]

Woops, @jwiegley. :)

[ekmett]

@BartMassey. Are you experiencing this problem any more?

[BartMassey]

Now I can't build lens at all :-)

trying: lens-3.6
rejecting: linear-0.2.0.2 (conflict: lens==3.6, linear => lens>=2.9 && <3.1)
rejecting: linear-0.2 (global constraint requires ==0.2.0.2)

[ekmett]

Hrmm. That is a depressingly old version of linear that shouldn't be part of the current set of packages for stackage.

The current version of lens in stackage is 3.6.0.3, not 3.6, and that version of linear has never been a current build in stackage.

You didn't make the mistake of running stackage init back when that was in the build instructions did you?

Can you try to cabal update before rerunning stackage build?

[snoyberg]

I haven't heard any more reports of lens failing. Any objection to closing this issue?

[ekmett]

So far, the three users who have reported the issue had containers installed outside of stackage. It appears that doctests run from within stackage can see those other versions, and the ghci used by doctest just takes the most recent unhidden version, and this is what was causing the error. Anyone who has a clean build and builds stackage, does not see the error.

At this point, I consider the issue resolved, modulo the fact that Simon and the doctest guys might want to look into whether or not there is a better way to deal with the sandboxing environment variables you send them.

[ekmett]

I spent some time revisiting this issue as there was slightly more I could do.

I've pushed out lens 3.7.1.2 which backports from HEAD a custom build step to build a file with all of the exact dependencies of the current project and then launches doctest with -hide-all-packages -package=... on those exact versions. This should fix any lingering errors caused by the fact that doctest can 'see outside of stackage' for other versions, and will allow me to deal with other packages being added to stackage that conflict with the module names in my dependencies. It hasn't happened yet, but someone might drag in monadLib or something.

So consider this issue doubly-closed. ;)

In case someone anyone else is dealing with similar issues with doctests in their package, they can find the custom build step and how it is used in this patch: ekmett/lens@ef535e5

[ekmett]

Correction: When hackage is back online, I'll push out 3.7.1.2 ;)