search

reflex-frp / reflex

Interactive programs without callbacks or side-effects. Functional Reactive Programming (FRP) uses composable events and time-varying values to describe interactive systems as pure functions. Just like other pure functional code, functional reactive code is easier to get right on the first try, maintain, and reuse.
https://reflex-frp.org
BSD 3-Clause "New" or "Revised" License
1.07k stars 149 forks source link

Dependencies on multiple versions of haskell-src-exts #309

Open endgame opened 5 years ago

endgame commented 5 years ago

On nixpkgs master (at least as of 395bcc0b27ce0d3c8a9af09737ba076a089a8dd6), I can't get reflex-0.6.1 to build using because it's indirectly depending on two different versions of haskell-src-exts ( https://pastebin.com/BnHagELV ). I am not sure if this is reflex's fault, or how to diagnose this. If you can give me pointers I can go digging, or refile this issue somewhere better.

It would be very cool to be able to get an 0.6-series reflex through straight nixpkgs, and we're almost there.

endgame commented 5 years ago

Is there any chance of pushing a metadata revision for the 0.6.1 release, allowing haskell-src-exts < 1.22? That would go a long way to fixing this. I think you'd be able to close the reflex issue after that, and I can take the rest up with nixpkgs.

Ericson2314 commented 5 years ago

We recommend using https://github.com/reflex-frp/reflex-platform. Nixpkgs shouldn't be doing overrides that break package-version coherence, so if there is some override there that just affects one of haskell-src-meta or reflex that should be changed to affect the whole package-set.

endgame commented 5 years ago

Nixpkgs seems to override haskell-src-exts in three places: hlint, hoogle and lambdabot-plugins. The reason it affects package coherence here is because of the reflex test suite that wants the codebase to be hlint-clean.

Ericson2314 commented 5 years ago

Ah. hlint isn't used as a library right? It should be a build-tool-depends. That might help (should be separate package db).

endgame commented 5 years ago

Alas, no: https://github.com/reflex-frp/reflex/blob/develop/test/hlint.hs

ryantrinkle commented 5 years ago

I don't think there's a major problem with us changing the way we invoke hlint, if that is helpful.

On Tue, Jun 11, 2019 at 8:54 PM endgame notifications@github.com wrote:

Alas, no: https://github.com/reflex-frp/reflex/blob/develop/test/hlint.hs

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/reflex-frp/reflex/issues/309?email_source=notifications&email_token=AAI2KYEQC2DHAFMNS47TYQLP2BCM3A5CNFSM4HNICF5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXO5RWA#issuecomment-501078232, or mute the thread https://github.com/notifications/unsubscribe-auth/AAI2KYDM6T735DJWEKXGDADP2BCM3ANCNFSM4HNICF5A .

endgame commented 5 years ago

I think it would be. Seems like the right thing to do is make hilnt a build-tool-depends, and have the hlint test invoke hlint in a subprocess?