Regression in 2.0: cabal v1-install happy fails with mysterious interface error

[andreasabel]

Lifted from:

• Broken CI/haskell installation on GitHub? agda/agda#7507

CI failure due to happy-2.0: https://github.com/agda/agda-stdlib/actions/runs/11030950764/job/30636656269#step:6:34

$ cabal v1-install happy
...
Building executable 'happy' for happy-2.0.2..
[1 of 2] Compiling Paths_happy      ( dist/build/happy/autogen/Paths_happy.hs, dist/build/happy/happy-tmp/Paths_happy.o )
[2 of 2] Compiling Main             ( app/Main.lhs, dist/build/happy/happy-tmp/Main.o )
/home/runner/.cabal/lib/x86_64-linux-ghc-9.8.2/happy-lib-2.0.2-EgcIv144oLmqXufj3QhQk/Happy/Backend/LALR.hi
Declaration for lalrBackendDataDir
Unfolding of lalrBackendDataDir:
  getDataDir1 ErrorWithoutFlag
                Something is amiss; requested module  happy-lib-2.0.2-EgcIv144oLmqXufj3QhQk-backend-lalr:Paths_happy_lib differs from name found in the interface file happy-lib-2.0.2-EgcIv144oLmqXufj3QhQk-backend-glr:Paths_happy_lib (if these names look the same, try again with -dppr-debug)

<no location info>: error:
    Cannot continue after interface file error

So it looks like v1-install does not work for happy anymore.

Maybe we should reconsider using the interal libraries feature that cabal does not support fully yet.

• v1-install fails with internal libraries cabal#8733

A proper support by cabal would be at least an error message stating that v1-install does not work with internal libraries.

[andreasabel]

What limits the impact of this regression is that cabal v1-install foo with happy in the build-tool-depends will not cabal v1-install happy, but just complain that there is no happy in the PATH.
So the situation can only be triggered by cabal v1-install happy itself.
In practice, there is no need to use cabal v1-install for an executable over cabal v2-install.

So maybe all that is to be done here is to bug the Cabal developers to handle the situation of internal-libraries with v1-install properly as opposed to just driving by GIGO.

[sgraf812]

I'm beginning to think that happy-lib should not use internal libraries. For an important ecosystem tool such as happy, there are just too many papercuts. Even if haskell/cabal#8733 gets fixed, I'm not sure it is acceptable to support v1-install only in Cabal 3.14 and later; this would be an unforced breaking change on many clients.

So I propose the following:

• Do not use internal libraries in happy-lib/vendor
• To guarantee separation of concerns (as @Ericson2314 suggests), add another happy-lib-sep.cabal file which looks like the current happy-lib.cabal file. This file maintains the internal libraries separation and is built as part of CI. The net result is that we build everything twice, but since happy-lib-sep.cabal is not a dependency of the executable I hope that we don't need to build everything twice all that often (except when running cabal test).

[sgraf812]

A low maintenance alternative might be to instead add commented imports. Easier exemplified than explained.
In Happy.Tabular.Nameset, add

> import Happy.Grammar () -- See Note [Separation dependency]

(I see that NameSet already has this dependency. Bother.)

This dependency expresses that the "top" module in the dependency hierarchy of happy-grammar should be built before the "bottom" module of happy-tabular. (In general, there are no unique tops or bottoms, so perhaps this should rather be "sinks" and "sources".)

Another example: In Happy.Backend.LALR, add

> import Happy.Tabular () -- See Note [Separation dependency]

and so on.

Now, if there's ever a violation of the separation that the package declarations would enforce, we will get a cyclic import error.

[int-index]

v2- commands have been the default in cabal-install for a while now. I'm not at all worried about compatibility with v1- commands, which will eventually get removed/deprecated anyway.

[Ericson2314]

Yes in general I am sympathetic that we can only get away with saying "actually it's a Cabal bug" so many times, but in this case I agree with @int-index, I have no sympathy for anyone that insists on using v1 commands in 2024. And indeed no on at the Agda side was actually insisting on this.

agda/agda#4627 (comment) I left this comment because I think the Agda comment is just plain out of date at this point.

[sgraf812]

I'm hesitant if it's a good idea for us to make an unforced change that in turn forces hundreds of Agda users to change their workflows... I would rather hear from other Agda users that they are fine with v2-install.

[Ericson2314]

@sgraf812 Well they already changed their CI? It's not clear to me at least that they want anything more from us.

[sgraf812]

Well, the comment you cited indicated that the Agda team recommends its users to install Agda with v1-install. Changing that recommendation would break a lot of habits and existing documentation.

Although upon searching in https://agda.readthedocs.io/en/latest/, there aren't that many mentions of v1-install.

As I said, we should ask people who know how many people are affected by this.

Ah, it may be that Agda users aren't really affected by this because cabal v1-install Agda will just use the happy in $PATH. Anyway, I'm confused enough to wait for a response from an Agdress (sorry, couldn't resist).

[Ericson2314]

Yeah I am fine waiting too. But my guess is this is basically a stale comment (that, according to the one person, linked the wrong issue too). I imagine we'll all be a bit confused at first :).

[andreasabel]

So yes, what I was trying to say is that it should not be a big problem for Agda users, as the official installation instructions do not recommend v1-install unless you want to install the development version. But even then, it says to cabal install happy first which would not cause the present issue.
So we could hope that no more complaints come in...