haskell-src-exts-1.18.0 is out of bounds for:
hlint-1.9.36 released which fixes one HSE issue.
hoogle-5.0.2 released which fixes another HSE issue.
Also note that the haskell-src-exts test suite can be re-enabled as well once constraint is lifted.
Homplexity has been updated.
Michal
Pozdrawiam
Michał
Be aware that pointful-1.0.8 doesn't build correctly with haskell-src-exts-1.18: https://github.com/23Skidoo/pointful/issues/10
Be aware that due to the changes in haskell-src-exts _nothing_ on this list is likely to build correctly without some changes.
Right, I only mention pointful since it's not on the list at the moment. (The haskell-src-exts upper bound for pointful-1.0.8 has since been revised, however.)
The page at https://www.stackage.org/lts-6.9/package/haskell-src-exts-1.17.1 shows there are 137 packages. However, not all of those are themselves in Stackage. Any way to get the list of packages that are both in Stackage and depend on haskell-src-exts? Perhaps the Stackage website should list the depended upon in two separate sections. Essentially all 137 packages are broken by this release, the question is how many also impact stackage.
Here you go (copied from https://raw.githubusercontent.com/fpco/stackage-nightly/master/nightly-2016-07-27.yaml):
haskell-src-exts:
users:
That suggests the following authors need to at least test with HSE, and almost certainly need to make code modifications:
file-modules compiles and works with 1.17.1.
Yeah, a user just reported me that haskintex was failing to build. It was because of haskell-src-exts. I uploaded a new version (0.7.0.0) that works with the newest haskell-src-exts.
Thanks, will get back with hprotoc fixes in 2-3 years estimated https://twitter.com/ko_bx/status/759717177381515264 !
Hi Konstantin
It is just parametrizing all AST types by new SrcLoc/SrcSpan etc
Took me just a weekend to fix - please Gitter me privately if You need help.
Cheers
Michal
On Mon, 1 Aug 2016 at 4:09 AM, Kostiantyn Rybnikov [email protected]
wrote:
Thanks, will get back with hprotoc fixes in 2-3 years estimated
https://twitter.com/ko_bx/status/759717177381515264 !—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fpco/stackage/issues/1734#issuecomment-236453618, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAp12VZREfVqLr6YO7hbplY7uyjwdtkMks5qbQDugaJpZM4JTsh1
.
stylish-haskell has been updated.
@jaspervdj sometimes it's worth to look on pull requests tab: https://github.com/jaspervdj/stylish-haskell/pull/121 :(
@phadej Ah, somehow I missed that mail, sorry :-(
I've requested removal of derive from Stackage, which solves the upper bound issue: fpco/stackage#1772
I note we are starting to drift towards the 1 month ideal upper bound on how long such upgrades take.
@yamadapc the question is about 1.18!
I don't think I'll have time to fix fay so feel free to disable it if need be.
Next version of hindent (5.0.0) when published will work with 1.18.
@chrisdone jfyi, hindent-0.4.6 works fine with GHC 8 after fixing the upper bounds. Unfortunately you locked the issue at https://github.com/chrisdone/hindent/issues/203 (why?). So I can't paste the new build-matrix report demonstrating this... :-/
hindent 5.0.0 published, works with 1.18.
Sorry, I think missed the version nº. [email protected] supports 1.18
Turns out it was pretty easy so fay has been fixed!
New entries:
With all the hindent buzz flying around I think we should try to get the latest version in nightly ASAP. That depends on closing this issue.
I have published haskell-names-0.8.0 which is compatible with haskell-src-exts-1.18.*, sorry for my ignorance what do I have to do now?
thanks @phischu! That's all AFAIK, we'll let you know if anything else pops up.
Unfortunately removing this upper bound is disabling packages of unseen proportions, granted some of this might be because of benchmarks/test suites. But still, read and weep.
I'l try to figure out if there's anything we can or should have done to make this more transparent...
It is in some sense much better than it looks ;-) It just turns out that there are a lot of transitive dependencies on haskell-src-exts. And some very popular packages are included here.
@ndmitchell: Worth noting, is that derive is still an issue. We removed it from build-constraints, but it is still included since other packages depend on it. It is obvious in hindsight that we should have put in a "derive < 0" constraint to test the removal, and I suppose the reason we missed this is that very few packages are explicitly removed from stackage. As I understand it you just removed derive because of lack of time, correct?
I'm sure Neil would appreciate if someone in this list could help out!
derive depended on by:
haskell-src-meta doesn't have a stackage maintainer so what we should have done is check the transitive dependencies at once to inform these people that they together are responsible for it. Upstream issue: https://github.com/bmillwood/haskell-src-meta/issues/57
haskell-src-meta depended on by:
@stepcut: Pretty much your whole package set is affected because of
hsx2hs which you also maintain, so that one is on you unfortunately :)
hsx2hs depended on by:
@bergmark Ah, yes, hello. I've been summoned. What's the CTA here? What do you want me to do?
What action needs to be taken for packages which depend on haskell-src-meta?
@bitemyapp bloodhound among others depend on derive which doesn't allow haskell-src-exts 1.18.*, so conjointly the maintainers with packages depending on it should make sure a fix gets released, or remove the dependency (which is probably impractical in this case).
@tmhedberg Likewise for haskell-src-meta dependent maintainers, someone needs to write a patch to support haskell-src-exts 1.18.*.
As a last resort; if the maintainer is not accessible hackage trustees can help out. For that, create an issue in the trustee repo
I'm not the maintainer of QuasiText, I'd tried to add it to stackage in an attempt to get Elm to build on the FPComplete online editor. That's obviously not going to happen now, so if it needs to be removed it won't break anything for me.
In short, I don't have the knowledge or use-case to maintain QuasiText or haskell-src-exts.
I ported 80% of derive, then got bored - the code is at https://github.com/ndmitchell/derive/issues/19. I suspect it's quite feasible to finish the port.
I also advertised for an alternative maintainer at https://github.com/ndmitchell/derive/issues/6, to which @tomberek and @mgajda responded with positive noises.
My main reason for removing the package from Stackage is because I don't use it, and I'd like to trim my package set. I would encourage others to take it forward, and might be persuaded to give it one last shove over this line, but probably not the next line or the one after that.
FYI, I just realised that fortran-src doesn't actually need the derive dependency anymore, so I have removed that.
Re my haskell-src-meta dependency for codo-notation- I can look into that soon.
Its worth noting that I'm responsible for adding the derive dependency for ua-parser and probably bloodhound since I work on that also. Its only used for the test suite and I use it to derive quickcheck instances. I do this so that when new constructors and fields get added to types that the tests fail if they are not accounted for. There have been efforts to add Generic-based Arbitrary derivations that would allow for dropping derive in my use cases but they have stalled out.
I've gone ahead and submitted a mergeable PR on QuickCheck. If that PR gets merged, I'd be willing to update bloodhound, ua-parser, and uri-bytestring test suites to use the new QuickCheck rather than derive. Do note that because it would be a brand new QuickCheck, I'd have to put an extra-deps in the stack.yaml until nightlies got caught up. I'm not sure how the logistics on the stackage side would work out there. I'm either going to use derive or new QuickCheck, but I'm certainly not going to write out all those instances by hand :)
@MichaelXavier - that seems a much better way to go forward long term. You are using about 0.5% of derive, so it's cracking quite a small nut with a huge hammer I don't want to maintain :)
If anyone else is blocked because of derive, let me know, and I can see what can be done - otherwise I've paused my efforts and left the https://github.com/ndmitchell/derive/tree/hse-1.18 branch around if anyone wants to pick up the work.