Skip to content
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

new-test for non-local dependencies #5511

Open
quasicomputational opened this issue Aug 10, 2018 · 0 comments
Open

new-test for non-local dependencies #5511

quasicomputational opened this issue Aug 10, 2018 · 0 comments

Comments

@quasicomputational
Copy link
Contributor

Currently, trying to new-test a package that's not a local dependency fails with this message:

$ cabal new-test lens
Resolving dependencies...
cabal: Cannot test the package lens because none of the components are
available to build: the test suite 'templates', the test suite 'properties',
the test suite 'hunit' and the test suite 'doctests' cannot be built because
cabal does not currently support building test suites or benchmarks of
non-local dependencies

I think this would actually be a useful feature to have. Consider the situation where you have two local packages, A and B. A depends on a non-local package C, and C depends on B. Being able to test C against the local version of B to ensure compatibility pre-release would be quite nice.

This situation can arise naturally: until recently, html-conduit depended on tagstream-conduit which depends on xml-conduit; html-conduit and xml-conduit are maintained as a megarepo, but tagstream-conduit is separate. Alternatively, this situation can arise when A, B and C are in a megarepo and the user wishes to test A and B against the released version of C before releasing them.

In the latter case, the user will explicitly know which non-local dependencies they'd like to test against. However, the former is a bit more complicated: it may be unknown to the user that C depends on B. Perhaps some way of saying 'test all local dependencies plus all the non-local dependencies in the build plan that (transitively) depend on a local dependency' is needed?

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