Conversation
|
Can we revert to the original Feynman.cabal and drop hpack? I'd prefer to maintain via cabal and use stack to provide a reproducible build on top of cabal to fall back on. |
|
That's absolutely doable -- I'll update the PR... eventually... One thing though: there's a process interaction here that's maybe not totally obvious, that in the hpack yaml file I've removed all the version specifications from the library dependencies. That's the real advantage of Stack IMO: you are no longer thinking about version dependencies directly, the problem is reduced to "which Stackage package set am I working with?" So yes reproducible builds, but also sets of libraries that are likely to work well together. There's a bunch of stuff in there with version specs that I don't know if the constraints are even meaningful. Like, I'm sure Feynman doesn't build if you select the very first version of every dependency, but beyond some minimum, are there interactions? Bugs fixed or introduced in specific versions that matter? If you personally have a policy about it I'd like to know it, otherwise I feel that taking version numbers off is probably better -- and just get latest by default. But what I like best is having a blessed Stackage version, and then versions that are close to that probably also work, and anytime you feel like things are getting too stale you can update to a recent Stackage LTS and at least you get any pain over with all at once, efficiently. |
|
In case it wasn't clear, which I think it wasn't, the buried question is,
Along the same lines:
In general I find it removes mental load if I know that for a whole project, I've got the same language extensions and libraries, and I develop an idiom around that. |
Like the description says