Skip to content

Conversation

@jlunder
Copy link
Collaborator

@jlunder jlunder commented Feb 26, 2025

Like the description says

@jlunder jlunder mentioned this pull request Feb 26, 2025
@meamy
Copy link
Owner

meamy commented Mar 10, 2025

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.

@jlunder
Copy link
Collaborator Author

jlunder commented Apr 9, 2025

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.

@jlunder
Copy link
Collaborator Author

jlunder commented Apr 9, 2025

In case it wasn't clear, which I think it wasn't, the buried question is,

  • may I remove version specifications from dependencies in the cabal file when it's reverted?
  • if you'd rather keep them, what is the policy? (e.g. "we always have guaranteed minimums and allow point upgrades but not major upgrades", or "we only specify a minimum in cases where we've seen actual conflicts", or...)

Along the same lines:

  • may I rationalize all the default language extensions used?
  • may I rationalize the dependencies between tools? (Or e.g. are we trying to be strictly minimal?)

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants