Skip to content

Unify Cabal/cabal-install package/integration Cabal samples #3667

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ezyang opened this issue Aug 4, 2016 · 5 comments
Closed

Unify Cabal/cabal-install package/integration Cabal samples #3667

ezyang opened this issue Aug 4, 2016 · 5 comments

Comments

@ezyang
Copy link
Contributor

ezyang commented Aug 4, 2016

I recently realized that there is a substantial amount of duplication between Cabal's package-tests and cabal-install's integration-tests. Take any particular Cabal test: it consists of some Cabal files, some source files, and some instructions how to build it (in Haskell code). Create a cabal.project or sandbox, and now those exact same Cabal files can be run using cabal-install. Since there is some amount of duplication between the functionality that Cabal and cabal-install provide, it would be beneficial if we specified the test files only once, and then specified for Cabal and cabal-install separately how to actually run them. It also helps with the problem where we have two substantially similar drivers for both types.

I've been pondering how to do this. I think the answer is that we should create a separate Cabal project (assuming the driver is written in Haskell; it doesn't have to be) just for tests. The driver tests either a Setup executable, or a cabal executable, and each test is associated with all of the various ways you can build the project in question (e.g., a hopefully short cabal new-build invocation, or a longer sequence of Setup invocations). You can write your test script either as a shell script or a self-contained Haskell program (the driver is responsible for runghc'ing these test scripts; decoupling in this way will help alleviate some of the complaints with an entirely Haskell driven interface).

What do people think?

@23Skidoo
Copy link
Member

23Skidoo commented Aug 4, 2016

+1 from me, I think that merging the two test suites makes a lot of sense. Would be also nice to move unit tests to the same top-level location, but this will have to wait until cabal-install code is exposed as a library.

@ezyang
Copy link
Contributor Author

ezyang commented Aug 16, 2016

I'd like to avoid doing this before per-component and Backpack branches merge.

@ezyang
Copy link
Contributor Author

ezyang commented Aug 16, 2016

integration-tests2 poses a problem, because it needs to build against private cabal-install modules. Probably can't separate it out.

@ezyang
Copy link
Contributor Author

ezyang commented Nov 25, 2016

Since the package tests rewrite landed, this is a lot closer. We just have to port the cabal-install tests to the new test runner. I have some patches on the way.

@ezyang
Copy link
Contributor Author

ezyang commented Nov 28, 2016

This is fixed!

@ezyang ezyang closed this as completed Nov 28, 2016
@ezyang ezyang added this to the 2.0 milestone Nov 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants