Can everyone please update your code to the latest QuickCheck, Parsec, and HaXml this week? Thanks!

Hello, I keep running into issues where I want to use some version of parsec, quickcheck, haxml, etc, in my code, but my code links against a different third party library (e.g. network) which uses a different version of the library (e.g., parsec) than what I want to use, and that makes cabal unhappy. If I use, runhaskell Setup.hs configure, I get warnings like: ~/n-heptane/projects/haskell/web-routes/web-routes-happstack $ runhaskell Setup.hs configure --user Configuring web-routes-happstack-0.18... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package network-2.2.1.7 requires parsec-2.1.0.1 package hsemail-1.3 requires parsec-2.1.0.1 package happstack-util-0.4.3 requires parsec-2.1.0.1 package happstack-server-0.4.3 requires parsec-2.1.0.1 package web-routes-0.18 requires parsec-3.1.0 Now, the project actually builds and runs fine, because the code in network that uses parsec and the code in my library that uses parsec do not interact at the parsec-level at all. But, cabal install can not handle this, because it (currently) can't *know* that it's actually going to work. Now, parsec and quickcheck are in the haskell platform. So, that should drive a lot of packages to use the same versions. But what about libraries such as HaXml which are not in the platform? Or what about this case where I want parsec 3, even though parsec 2 is in the haskell platform? Any ideas about what should be done? We have this problem with QuickCheck and happstack when people try to cabal install gitit. And I am running into the problem again with the urlt / web-routes library. - jeremy

Jeremy Shaw
I keep running into issues where I want to use some version of parsec, quickcheck, haxml, etc, in my code, but my code links against a different third party library (e.g. network) which uses a different version of the library (e.g., parsec) than what I want to use, and that makes cabal unhappy.
Better (well, OK, maybe not _better_ per se but relevant) question: why isn't QuickCheck usage optional in so many of these libraries? There should be no reason for most people to build the testing functions, etc. in these libraries. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

From a source code management viewpoint, it is nice to have the unit tests in the package (such as happstack-data) so that we don't have twice as many
In the case of happstack, the happstack-util library provided a function that converted QuickCheck unit tests into HUnit unit tests. happstack-util exported this so that the other happstack-* packages could use it as well. We did not actually have the unit tests themselves enabled by default. Though that is actually a problem as well. The theory (at the time) was that every happstack-* package would export its unit tests. The top-level happstack package could then import all the unit tests into a bigger testsuite and run them all. (And the bigger testsuite would be re-exported so that you could include the happstack testsuite in your applications own test suite). packages to deal with, and so that the source for the unit tests is included when you get the package from hackage. We should not simply make the unit tests be a compile time flag in the .cabal, because there is no way for the happstack parent package to depend on the version of happstack-data (for example) which has the unit tests enable. So, the only solutions are: 1. always export the unit tests 2. create a separate cabal package for each happstack package which just contains the unit tests. The first option is much easier -- except that it requires QC, which is especially problematic at the moment. So ultimately, we will have to move to the second option I guess. As a work around, we did just make all the QC related stuff enabled via a flag. But it does cause problems when trying to build the test suite in the buildbot because happstack-data gets rebuilt with out the tests enabled :( - jeremy On Sun, Mar 28, 2010 at 6:35 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:
Jeremy Shaw
writes: I keep running into issues where I want to use some version of parsec, quickcheck, haxml, etc, in my code, but my code links against a different third party library (e.g. network) which uses a different version of the library (e.g., parsec) than what I want to use, and that makes cabal unhappy.
Better (well, OK, maybe not _better_ per se but relevant) question: why isn't QuickCheck usage optional in so many of these libraries? There should be no reason for most people to build the testing functions, etc. in these libraries.
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On 29 March 2010 11:11, Jeremy Shaw
We should not simply make the unit tests be a compile time flag in the .cabal, because there is no way for the happstack parent package to depend on the version of happstack-data (for example) which has the unit tests enable.
Yes, this is a problem. especially if this was an option but flags introduce conflicting APIs and two packages want the same package as a dependency but with conflicting compile-time flags. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
participants (3)
-
Ivan Lazar Miljenovic
-
Ivan Miljenovic
-
Jeremy Shaw