This project is mirrored from Pull mirroring updated .
  1. 07 Jan, 2016 4 commits
    • Edsko de Vries's avatar
      Introduce RepoContext · ba5c55c4
      Edsko de Vries authored
      The RepoContext encapsulates the list of repositories, as well as some
      associated state. In particular, it also encapsulates the HttpTransport, which
      will be initialized on demand and cached thereafter.  This is important for two
      * For the hackage-security integration: in order to be able to use cabal's own
        HttpTransport API for the secure repo, we need to have access to that
        transport when we initialize the repo, but as things stood that was not
        possible (cabal was initializing repos ahead of time but the transport on
      * For the integration with the nix-local-branch it is important that the Repo
        type remains Serializable. By passing RepoContext rather than a list of
        Repos, we can leave RepoSecure serializable and separately maintain a mapping
        from cabal's Repo type to hackage-security's (stateful) Repository type.
    • Edsko de Vries's avatar
      Move GlobalFlags to its own module · 71609ec1
      Edsko de Vries authored
      This is in preparation for the next commit (and will avoid circular
      module dependencies).
    • Edsko de Vries's avatar
      Merge pull request #3031 from edsko/pr/requestHeaders · 710659cc
      Edsko de Vries authored
      Add support for request headers in getHttp. Merging since approved.
    • Edsko de Vries's avatar
      Merge pull request #3029 from edsko/pr/readBuildTreeRefsFromCache · 6a41080c
      Edsko de Vries authored
      Improve separation of concerns: introduce readBuildTreeRefsFromCache. Merging since approved. 
  2. 06 Jan, 2016 4 commits
  3. 05 Jan, 2016 3 commits
  4. 04 Jan, 2016 1 commit
  5. 03 Jan, 2016 2 commits
  6. 02 Jan, 2016 2 commits
  7. 31 Dec, 2015 1 commit
  8. 30 Dec, 2015 2 commits
    • randen's avatar
      Add foldl' import · 6a62d2d2
      randen authored
      -- building cabal-install in a sandbox with add-source
      on Cabal, still builds the cabal executable even though
      the Cabal build failed :-(
    • randen's avatar
      The Cabal part for fully gcc-like response files · 0384727a
      randen authored
      * Cabal/Distribution/Simple/Haddock.hs
        * VERY IMPORTANT! this feature depends on a particular
          version of haddock, that includes the corresponding
          support for these style of response files.  However,
          we do not really know that version number!  So, this
          change here must be co-ordinated with the haddock project.
  9. 29 Dec, 2015 3 commits
  10. 28 Dec, 2015 4 commits
    • Edward Z. Yang's avatar
      Failing test for #3004. · 0e4d34e2
      Edward Z. Yang authored
      Signed-off-by: default avatarEdward Z. Yang <>
    • Erik de Castro Lopo's avatar
    • Edward Z. Yang's avatar
      Rewrite the package test suite. · e94552e8
      Edward Z. Yang authored
      I've rewritten the test suite to be more concise and "correct by
      construction".  The primary method that this is achieved by
      is introducing the 'TestM' monad, which carries around the
      important state for the tests so that (1) we don't have to
      pass it as an argument all around, and (2) we can automatically
      make the correct decisions about how to do things.  This new
      method emphasises "configuration by convention": we assume
      that a test-case named "Foo" has its test packages in the
      directory "tests/PackageTests/Foo".
      A secondary change is that all command functions automatically fail if
      they have a non-zero exit code (unless you use the 'shouldFail'
      combinator which inverts the sense.)  This saves a lot of typing
      on test-cases.  (In fact, I've reorganized all of the commands
      related here.)
      In the process, I've tightened up the logic for how to find the
      LocalBuildInfo of the Cabal we've testing, so we should now
      reliably be testing the inplace Cabal library, and not the
      system library (as was often the case.)
      Because things are a lot shorter, there is no good reason to
      make Check modules except for the biggest test cases.  Most
      test-cases have been folded into PackageTests.Tests; if you
      have a small test-case you should just put it there.
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
  11. 27 Dec, 2015 2 commits
  12. 26 Dec, 2015 1 commit
  13. 24 Dec, 2015 1 commit
  14. 23 Dec, 2015 2 commits
  15. 22 Dec, 2015 2 commits
  16. 21 Dec, 2015 6 commits