happstack-util dependencies on testing libraries
Max Bolingbroke
With a few small changes it is possible to stop happstack-util from
depending on QuickCheck and HUnit. This is potentially useful because
it reduces the possibility of happstack-util being non-installable due
to a conflict with the QC/HUnit version some other package requires.
The modifications to the Cabal file are:
1) Only depend on those two modules if we are using flag(tests):
if flag(tests)
Build-Depends: QuickCheck < 2,
HUnit
(Remove those packages from the main Build-Depends list)
2) Only expose Happstack.Util.Testing if we are using flag(tests):
if flag(tests)
Exposed-modules: Happstack.Util.Tests,
Happstack.Util.Testing
(Remove Happstack.Util.Testing from the other exposed-modules list)
The package builds successfully after making those changes.
A problem may arise if the other happstack packages make use of
Happstack.Util.Testing, which I assume they do. In that case, you will
need to manually ensure that you build happstack-util with -ftests
before building any of the dependencies, because cabal-install can't
deal with the situation where the package API changes in response to
flag settings, and so won't know to set -ftests on the happstack-util
build even if you set -ftests when building one of the packages that
depends on -utils.
The Right Thing is to split that module into a package all of its own
(happstack-test-utils maybe) which depends on happstack-utils and is
then depended on by other packages only when their own -ftests flag is
set -- but that's considerably more fiddly than the Cabal file
fiddling proposed here.
I think this change is valuable despite this caveat -- if any evidence
was needed of its usefulness, it seems that the QuickCheck dependency
is causing problems for users that install gitit (http://
article.gmane.org/gmane.comp.lang.haskell.cafe/70087)
Cheers,
Max
stepcut
Would that resolve the issue as well?
- jeremy
Max Bolingbroke
> The version of happstack-utils in darcs has been updated to use QC2.
> Would that resolve the issue as well?
That should resolve this particular datetime dependency conflict. It
would perhaps be better avoid taking dependencies that aren't really
necessary for the package to run, though - what happens when HUnit 2
comes out? :-)
Cheers,
Max
stepcut
Then we will upgrade to HUnit 2 :)
Here is the deal with the happstack unit testing framework:
happstack is a collection of related, but non-essential packages. For
example, happstack-state and happstack-server do not depend on each
other. So, you can just pick and choose the libraries you want to
install. This is nice, because it means you don't have to worry about
all those extra dependencies those packages have if you aren't even
going to use those packages.
We also want to have unit tests that are associated with each package.
And we want some nice way to run all the unit tests for all the
packages.
So all the libraries includes their unit tests in modules that are
exported along with the rest of the library modules. Each package
exports a unit test which runs all the other unit tests in that
package. The top-level happstack package then imports all the unit
test modules from the different packages, and creates a unit test
which combines all the unit tests from the other packages plus any
additional top-level unit tests. This epic unit test then gets
exported so that anyone can use it.
We also include in all the packages a simple program which runs the
unit tests for that app.
So if you install just happstack-state, you can run just the tests for
happstack-state by running, happstack-state-tests. And if you install
the top-level happstack, then you can run all the tests via happstack-
tests. And if you write your own app, you can even include the
happstack unit tests as part of your test-suite by just importing the
epic-unit-test function.
But, then for some reason I don't remember, we made the unit tests
conditional via the -ftests flag. Well, it seemed like a good idea at
the time, but it is the wrong thing to do. If you do, cabal install
happstack -ftests, it won't work because the -ftests flag does not get
passed to all the dependencies. So none of the other libraries will be
built with unit tests enabled, and so it will fail. Having the unit
tests conditional is a violation of cabal policy. The flags are not
allowed to change the exported API.
So, making the API even more dependent on the flags you compile with
is a step in the wrong direction I think. We should either remove the
tests flag and always compile the tests. Or we should split the tests
out of the main packages so that you can explicitly depend on them.
If we split them out, that raises additional issues. Do we make one
test package that contains all the tests, or do we have one test
package per main package (happstack-util-tests, happstack-data-tests,
etc). Having one test package per main package would be most in spirit
with the loose coupling of the packages. It would seem a bit odd if
happstack-state does not depend on happstack-server, but if you want
to run the testsuite for happstack-state you have to install happstack-
server anyway.
Also, if we do split the tests into separate packages, then we have to
make sure that we keep the main package and it's test package in sync
somehow.
Anyway, I am not opposed to splitting the tests into a separate
library. I am just not willing to be the one to do it :)
Also, the Haskell Platform will include QC2 by default, so this will
hopefully go away by itself eventually, which makes me even less
interested in spending my time on it :p
But, we should at the very least document the problem on the Download
page so that people know how to work around it for now. The source for
the website is here:
http://patch-tag.com/r/stepcut/happstackDotCom
I will glady accept a patch :)
And if someone wants to split out the unit tests, I will take a patch
for that too. Though I would suggest describing your plan for that
before doing the work so we can make sure it is sensible.
- jeremy
Max Bolingbroke
packages like happstack-utils-tests to avoid these "false"
dependencies. However, since all I'm trying to do is to get gitit
installing via "cabal install" without any hackery and don't have any
interest in happstack per-se, I'm content to just wait for the QC
situation to resolve itself!
Cheers,
Max