Factor the CLI executable into its own package

[patrickt]

Today the builders decided to recompile the universe from scratch because a cabal new-update gave us some new bugfixes. While the build time is unfortunate (see #88), I started thinking about a separate dilemma, to wit: as time goes on and we loosen/tighten library version bounds in response to new packages coming in over the wire, we risk introducing changes into the behavior of the semantic executable. Ideally we want the semantic library’s version bounds to be flexible, so as not to lock external consumers into a fixed library version. In contrast, we want executable builds to be reproducible, which means that a given release of the semantic command line tool should be built with a vetted, deterministic set of dependencies. Distributing both the library and the command line tool together in the same package—that is, trying to have flexibility and determinism simultaneously, in the same package—may render this difficult.

I think what would be more correct would be to have semantic and semantic-cli packages, and use cabal new-freeze to provide semantic-cli with a cabal.project.freeze file that specifies the specific versions to use if someone wants to cabal install semantic-cli (and get the same executable that we’ve vetted and tested, not one built against libraries that we don’t know from Adam). Sort of like how Cabal the library and cabal-install the tool are separate things. I think? The documentation on cabal new-freeze implies that this is the right thing to do:

For end-user executables, it is recommended that you distribute the cabal.project.freeze file in your source repository so that all users see a consistent set of dependencies. For libraries, this is not recommended: users often need to build against different versions of libraries than what you developed against.

It’s not clear to me how a separate semantic-cli project in the same repository (and I would very much hope to use the same repository rather than a whole new one) would work. Hopefully the cabal.project.freeze files that cabal new-freeze files take effect lexically viz. not applying to the semantic library.

Given the relatively small user base of semantic the CLI tool, I don’t think this a crisis, nor do I necessarily insist on absolute and infallible build reproducibility: at this stage, the chances of production breakage creeping in due to version-bounds churn is very low, especially given our PVP contracts. I do, however, want to have an answer to this before we finish #16.

[robrix]

I think what would be more correct would be to have semantic and semantic-cli packages, and use cabal new-freeze to provide semantic-cli with a cabal.project.freeze file that specifies the specific versions to use if someone wants to cabal install semantic-cli (and get the same executable that we’ve vetted and tested, not one built against libraries that we don’t know from Adam).

Agreed.

It’s not clear to me how a separate semantic-cli project in the same repository (and I would very much hope to use the same repository rather than a whole new one) would work. Hopefully the cabal.project.freeze files that cabal new-freeze files take effect lexically viz. not applying to the semantic library.

Are cabal.project.freeze files consulted relative to the .cabal file? Like, if we add semantic-cli/cabal.project.freeze will it be applied to semantic-cli only?

Alternatively, can we e.g. name the file cabal.project.freeze.blah and rename it in CI/when building release binaries?

[robrix]

Renamed the issue to reflect my by-fiat decision 😁

[patrickt]

A conversation with @hvr revealed that I’m conflating two desires: the desire for the dependency graph associated with Docker builds and release tarballs tracked in the repo, and the desire to get something up on Hackage. Hackage’s PVP guarantees mean that if we specify the version bounds correctly, we should be able to distribute an executable package with inexact version bounds, while still tracking release bounds in a freeze file used only in Docker and release builds.