Cabal file syncing

[IamfromSpace]

With the recent migration to GH action, I just noticed that a merge that didn't update the Cabal file didn't break builds that should have been broken. This makes sense, in that the Cabal builds only view the currently checked in version of the Cabal file, where as stack builds regenerate it.

Notably, however, we publish via stack, which will then regenerate the file. So in this case, the builds would succeed, but the published version would be broken, which is not good.

One option would simply be to sync things before Cabal builds via something like stack build --dry-run. However, in many ways this defeats the purpose of checking in the file at all. If we are to check it in, ideally that means that users can use this package with Cabal via git checkout and no additional effort.

It may make sense to abort the build if the generated file were not going to match. That should theoretically prevent merges that don't keep master in sync.

[IamfromSpace]

I'm thinking of taking this notion even further.

Something that's struck me recently: a version is just an interface.

I think with software today, we see a major conflict between stability and progress over versioning. Either poor interfaces are maintained forever, or improved interfaces are released and older ones are either abandoned or maintained at great cost. Though, I have consistently argued that the maintenance cost of multiple versions is lesser than net maintenance generated across the ecosystem in abandonment. Part of my argument has been that by utilizing git effectively, we don't need to pay double the cost for double the maintenance. However, it's not necessarily intuitive to do this well, and it's not free of pitfalls and its own form of toil.

An approach that might allow us to use something closer to "trunk based development" without abandoning previous versions, would be to have one code based that supports all major versions, where versions only have effect at the interface. For example, the breaking changes introduced in hal were fairly minimal. One exposed function was renamed, and a typeclass implementation was dropped. If these top level changes are compiled conditionally, the code base between the two versions is 99% the same. This means that both versions could get bug fixes and refactors more or less for free. By pushing the interface distinctions out to the edge, most code changes are not likely to involve them.

For the most part, this mostly leaves us with the challenge of metadata. My thinking is that by using something like dhall, we can generate the appropriate files per version supported as needed. dhall would give us the tools to manage conditionals and repetition among them. These files would be present on a develop branch, where primary development would take place. Then individual release branches and tags would point to code where the cabal files are pre-generated and checked in. master would point to the most recent version. This would probably leave hpack behind, and instead use dhall files.

Not sure when I'll have the bandwidth to take this on, but leaves plenty of time for anyone to call this out as crazy :)