Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Give opinionated version suggestions for new projects (particularly for js/wasm backend) #2285

Open
tysonzero opened this issue Nov 30, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@tysonzero
Copy link

Knowing what version of haskell.nix, nixpkgs and ghc to use seems rather unclear.

I'm currently on:

haskell.nix: 6e9c388cb8353b7d773cd93b553fa939556401ce
nixpkgs: 2311
ghc: 982

This more or less "works" modulo some minor interventions needed to get amazonka, filepath, geos, servant-jsaddle and web-push to build (version overriding/constraining, allow-newer and c-dep tweaks).

However I'd like to try and get a newer ghc working to see if js backend payload size has been brought down (my ~100 module ~6k LOC project creates a 34M js file), and knowing which combinations of the above are likely to work feels like a bit of a guessing game, and cache misses seem quite common.

The "Getting Started" link seems to mention newest haskell.nix + nixpkgs-unstable + ghc925, but of course that combo would not give me either the js or the wasm backend, and is also just a fairly old ghc version at this point, so I was wondering if a more opinionated "cutting edge" setup is suggested anywhere, and if not if it could be put somewhere obvious to help newcomers, particularly those looking to do any frontend dev where this stuff tends to be most challenging.

@tysonzero tysonzero added the enhancement New feature or request label Nov 30, 2024
@tysonzero
Copy link
Author

Ok just tried:

haskell.nix: 5a47cb688aa7f70bc843a30b9341e948becfcd0c
nixpkgs: unstable
ghc: 913

and I got:

       > Configuring library for binary-0.8.9.2..
       > Error: default-setup: The package has an impossible version range for a
       > dependency on an internal library: binary >=0 && ==0.8.9.1, binary >=0 &&
       > ==0.8.9.1, binary >=0 && ==0.8.9.1, binary >=0 && ==0.8.9.1, binary >=0 &&
       > ==0.8.9.1, binary >=0 && ==0.8.9.1, binary >=0 && ==0.8.9.1. This version
       > range does not include the current package, and must be removed as the current
       > package's library will always be used.

really confused by the error, perhaps it's debuggable, but seems like the above version combo may not be in solid condition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant