- cabal-devel - Haskell.org

patch applied (hackage-server): "Remove the JSON feature" and 1 others
by duncan＠lun.haskell.org 13 Feb '12

13 Feb '12

Wed Oct 12 18:24:51 BST 2011 Duncan Coutts <duncan(a)community.haskell.org> * Remove the JSON feature Ignore-this: 8e1577b487e73d2738409e4f95798ff0 We're going to factor it differently. Each feature can provide its resources in multiple formats: native, json, xml. This is a more modular way of partitioning things rather than having a JSON feature that tries to provide JSON representations of reseources for lots of other features. M ./Distribution/Server/Features.hs -2 R ./Distribution/Server/Features/Json.hs M ./hackage-server.cabal -1 Mon Oct 31 12:21:50 GMT 2011 Max Bolingbroke <batterseapower(a)hotmail.com> * Update to tar v0.4 Ignore-this: c339adc5a34a24a821ca7528fa5fba2e M ./Distribution/Server/Framework/BackupRestore.hs -3 +3 M ./Distribution/Server/Packages/Unpack.hs -5 +5 M ./Distribution/Server/Util/Index.hs -1 +1 M ./Distribution/Server/Util/ServeTarball.hs -1 +1 M ./hackage-server.cabal -1 +1

1 0

install with '--upgrade-dependencies' requires '--force-reinstall'
by Antoine Latter 11 Feb '12

11 Feb '12

I'm using a development cut of cabal install from a few weeks ago, so this may not be relevant anymore (I'll upgrade soon to try the changes to --enable-tests and install soon), but I found this behavior odd: When using 'cabal(-dev) install --only-dependecies --solver=modular --upgrade-dependencies' to test my package with new dependencies, I am then told I need to use the flag '--force-reinstalls'. Shouldn't this be implied by '--upgrade-dependencies'? Thanks, Antoine

3 3

Re: patch: --enable-tests and --only-dependencies
by Thomas Tuegel 10 Feb '12

10 Feb '12

On Fri, Feb 3, 2012 at 4:40 AM, Andres Löh <andres(a)well-typed.com> wrote: >> The way to handle tests for named packages would be to add a >> PackageConstraint for tests the way is already done for flags, but >> this is a lot more work because it would require getting deep into the >> dependency solver. However, it would make it easy to set the config >> flags during build for explicit targets so we could implement a test >> auto-run feature. > > When I rewrote the solver, I was actually surprised that test flags > are sort of bypassing the solver. I don't think it would be all that > difficult to build it into the new solver properly, *if* I'd know what > properly means. So if you can specify a reasonable behaviour you'd > expect from the solver, I can try to implement it. I looked at the top-down solver again to see if we could enable/disable tests and benchmarks through a constraint (the way flag assignments are done). To my surprise, it's not nearly as confusing as I thought it was the last time I looked at it (two years ago (!) during GSoC when I wrote that awful solver-bypassing test code). The attached patches do what I think we want. Test dependencies for targetted packages (named and source alike) are detected and installed, but '--enable-tests' is not propagated to dependencies. I only checked the top-down solver because I'm still not familiar with the modular solver. I also included a patch to automatically run the test suites when 'cabal install --enable-tests' is invoked and abort installation if the tests fail. I think this is a sensible default; if a user is going to ignore the results of the test suites, they probably don't want '--enable-tests'. Johan and Antoine: I tested my patch with some source packages I have around and the packages I could find on Hackage that have test suites, but that only assures me that '--enable-tests' does what _I_ think it should do. It sounds to me like you use this feature on a daily basis: could you try out this set of patches and let me know if this behavior meets your needs? Andres: I had to make a few changes to the modular solver to get cabal-install to compile with the new constraints, but I didn't go far enough to actually have the solver pull in the dependencies. I recorded these changes as a separate patch to make the changes more obvious. You understand the solvers better than I do; if I'm taking the wrong approach, please let me know. Otherwise, this is what I did outside the solvers, if you want to implement test and benchmark dependencies for the modular solver: 1. There is a new type, 'OptionalStanza', with two constructors indicating respectively that '--enable-tests' or '--enable-benchmarks' was specified. 2. Constraints are passed to the solver in the same way as flag assignments. The names of the target packages are determined, and a list [OptionalStanza] is associated with each. If a constructor is present in the list, that type of stanza is enabled. If the list is empty, neither tests nor benchmarks are enabled. When a solver is building an InstallPlan, it just needs to configure each package respecting the constraints to get the correct list of dependencies. Packages that aren't specified as targets will have no constraints, so they should be built without '--enable-tests' and '--enable-benchmarks'. Hopefully we can put this long-standing bug to rest! Thanks! -- Thomas Tuegel

3 5

Has anyone else had trouble with "cabal test" diverging?
by Ryan Newton 09 Feb '12

09 Feb '12

I've been running into this issue with cabal 0.10.2, but ONLY in conjunction with GHC 6.12.3. It's hard to make a small reproducer for (and therefore I haven't filed a bug yet), but you can see the below Jenkins run stalled for 2.5 days, whereas it should take minutes: http://tester-lin.soic.indiana.edu:8080/job/monad-par_github_master/JENKINS… Note that it *doesn't* burn CPU -- it deadlocks rather than spins. I replaced "cabal test" with a direct call to the test executable and I haven't seen this problem since. -Ryan

1 0

Updates of hackage-server and data loss
by Erik Hesselink 08 Feb '12

08 Feb '12

Hi all, We run hackage-server internally at Silk. Every time we update to a new version, it is unable to read our old data. Is the acid-state being versioned correctly? Or is this expected behavior? It is very annoying for us. If this is expected, is there a way to work around it? Erik

2 3

Re: patch: --enable-tests and --only-dependencies
by Andres Löh 03 Feb '12

03 Feb '12

[If you got multiple copies of this, then sorry -- I had to sort with which address I'm actually subscribed to cabal-devel.] >> The way to handle tests for named packages would be to add a >> PackageConstraint for tests the way is already done for flags, but >> this is a lot more work because it would require getting deep into the >> dependency solver. However, it would make it easy to set the config >> flags during build for explicit targets so we could implement a test >> auto-run feature. > > When I rewrote the solver, I was actually surprised that test flags > are sort of bypassing the solver. I don't think it would be all that > difficult to build it into the new solver properly, *if* I'd know what > properly means. So if you can specify a reasonable behaviour you'd > expect from the solver, I can try to implement it. > > Cheers, > Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com

1 0

patch: --enable-tests and --only-dependencies
by Antoine Latter 02 Feb '12

02 Feb '12

Hi Cabal, When trying to use "cabal install --enable-tests --only-dependencies" it appears to be passing the "--enable-tests" option down to the dependent packages during build. This isn't what I want at all - I only want to use the "--enable-tests" flag for the purpose of building an install plan. In addition, the dependency solver doesn't solve dependencies as if dependent packages would be built with "--enable-tests", so the "configure" step for these packages fails due to missing dependencies. My proposed fix is to strip the 'configTests' flag from the ConfigFlags after building the install plan but before doing the installation itself, because passing 'enable-tests' to the 'configure' step during 'cabal install' doesn't make much sense to me anyway. An alternative fix would be to have a separate set of config flags per source package to be installed, with --enable-tests only turned on for the original target packages. A patch is attached. Antoine

3 5

Paths_pkg fails to build with NoImplicitPrelude
by Dag Odenhall 20 Jan '12

20 Jan '12

Hello, A .cabal file like the following: Name: pkgname Library Extensions: NoImplicitPrelude Other-Modules: Paths_pkgname ... results in a failed build due to Paths_pkgname relying on ImplicitPrelude. It would be better if 1) Paths_pkgname could somehow ignore the Extensions listed in the .cabal file, or, 2) It simply included an import of Prelude or a LANGUAGE pragma enabling ImplicitPrelude, although this solution might still be prone to breakage by other extensions. -- Dag

1 0

Adding ldconfig to Distribution/Simple/Program/Builtin.hs
by Dave Tapley 13 Jan '12

13 Jan '12

The subject says it all really, could we add ldconfig to "the collection of unconfigured and configured programs"? This collection is defined in this module: Distribution.Simple.Program.Builtin Dave,

1 0

Patch to read package-specific cabal-install config
by Carl Baatz 10 Jan '12

10 Jan '12

Hi all, for packages that aren't for public consumption, we would like to specify a private Hackage repo location. The simplest way we could think of to do this was to read a config file in the same format as the user config (~/.cabal/config) from the current directory and let any flags set in that file override the user config. The attached patch implements this, reading any file with a .cabal-install extension (including '.cabal-install'). It errors out if more than one .cabal-install file is found or if there's a parse error on the .cabal-install file. Does this sound like a good idea? If not, any ideas for alternative ways of handling non-public packages? Many thanks, Carl

2 4