Warn when external Setup uses old Cabal

[ttuegel]

Fixes #707.

[mention-bot]

@ttuegel, thanks for your PR! By analyzing the annotation information on this pull request, we identified @23Skidoo, @dcoutts and @tibbe to be potential reviewers

[ezyang]

Looks good!

[dcoutts]

LGTM

[ttuegel]

This (apparently) exposes a bug on Linux with GHC < 8; I will investigate.

[ttuegel]

Turns out it's not a problem with GHC < 8, but rather with running the integration tests outside of cabal test: they pick up Cabal-1.24 instead of the development version. Any ideas why?

[ezyang]

So, the situation is that when we call "cabal" from the custom/plain.sh test, it uses the default package databases (the global and the user). That means that when the setup script is built, it is built using the Cabal from the user database.

I tried some junky hack to get the database to the right place but for some reasons the GHC versions mismatched; not sure what's going on!

[ttuegel]

So, the situation is that when we call "cabal" from the custom/plain.sh test, it uses the default package databases (the global and the user). That means that when the setup script is built, it is built using the Cabal from the user database.

Isn't that the correct database?

I tried some junky hack to get the database to the right place but for some reasons the GHC versions mismatched; not sure what's going on!

How are you setting the database?

Also, is the problem that cabal looks in a different database (between the plain and bootstrap tests), or is the problem that Cabal is installed in a different database?

[ezyang]

Isn't that the correct database?

Not when we use new-build to build the Cabal package. In that case, the inplace Cabal install is in dist-newstyle/packagedb (with dependencies on packages in .cabal/store). An inplace package is never installed to the user database. Note that package-tests (in Cabal) does some fancy footwork to compute where the inplace Cabal is, but that code isn't in integration-tests.

How are you setting the database?

I tried passing cabal some --package-db flags. My noodling is here: ezyang#4 (look at the end commits; master pointer is out of date.) It works locally for me but not on Travis; puzzling!

Also, is the problem that cabal looks in a different database (between the plain and bootstrap tests), or is the problem that Cabal is installed in a different database?

Not sure what you mean by bootstrap tests, but I suspect plain.sh is the only test which has checked stderr, which is why it is failing. (In fact, one of the custom setup tests specifically makes sure that it picks up the system Cabal, and not some other Cabal that a user happens to have in the user database.)

[ttuegel]

Not sure what you mean by bootstrap tests, but I suspect plain.sh is the only test which has checked stderr, which is why it is failing. (In fact, one of the custom setup tests specifically makes sure that it picks up the system Cabal, and not some other Cabal that a user happens to have in the user database.)

Yes, but it only fails when invoked directly, as in travis-script.sh. When running the integration tests through cabal as in travis-bootstrap.sh, the tests work. But, it sounds like this is due to the difference between build and new-build.

EDIT: No, this can't merely be due to build vs. new-build. When I build with cabal build locally, but run the integration test directly, it still fails.

[ezyang]

No, this can't merely be due to build vs. new-build. When I build with cabal build locally, but run the integration test directly, it still fails.

That's because the bootstrap strip also installs the Cabal library in the user database, which is why it gets picked up.

[ezyang]

Is there some alternate hacky fix we can do to get this PR unfrozen? @ttuegel

[ttuegel]

Is there some alternate hacky fix we can do to get this PR unfrozen?

The only way to get this PR moving again is to fix the test suite. I took a stab at it, but I couldn't figure it out.