This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 12 Jan, 2016 1 commit
  2. 07 Jan, 2016 1 commit
    • 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
      reasons:
      
      * 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
        demand).
      
      * 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.
      ba5c55c4
  3. 05 Jan, 2016 2 commits
  4. 04 Jan, 2016 1 commit
    • Duncan Coutts's avatar
      Switch to the tar package, drop builtin code · 0db3b216
      Duncan Coutts authored
      The current incarnation of the tar package originated as code inside
      cabal-install. That external tar package is now quite mature, with more
      features and is much faster. In particular the tar index features will
      be very useful for cabal-install, which currently has to maintain its
      own custom-format index/cache.
      0db3b216
  5. 27 Dec, 2015 1 commit
  6. 21 Dec, 2015 1 commit
  7. 18 Dec, 2015 1 commit
  8. 17 Dec, 2015 4 commits
    • Edsko de Vries's avatar
      Address comments on #2949. · ef6fe247
      Edsko de Vries authored
      This changes the definition of `Index` to
      
      ``` haskell
      data Index =
          -- | The main index for the specified repository
          RepoIndex Repo
      
          -- | A sandbox-local repository
          -- Argument is the location of the index file
        | SandboxIndex FilePath
      ```
      
      with
      
      ```
      cacheFile (SandboxIndex index) = index `replaceExtension` "cache"
      ```
      
      This also renames `repoRemote'` to `maybeRepoRemote`.
      
      I believe this addresses all comments.
      ef6fe247
    • Edsko de Vries's avatar
      Change Repo type · a8056d47
      Edsko de Vries authored
      The old Repo type has a repoKind
      
          repoKind     :: Either RemoteRepo LocalRepo,
      
      where LocalRepo was isomorphic to unit:
      
          data LocalRepo = LocalRepo
      
      This commit changes Repo to
      
          data Repo =
              -- | Local repositories
              RepoLocal {
                  repoLocalDir :: FilePath
                }
      
              -- | Standard (unsecured) remote repositores
            | RepoRemote {
                  repoRemote   :: RemoteRepo
                , repoLocalDir :: FilePath
                }
      
      instead, which is a little more idiomatic and will make adding more repository
      types easier.
      a8056d47
    • Edsko de Vries's avatar
      Introduce datatype for the Cabal index cache · 2cce2cb8
      Edsko de Vries authored
      Right now this just wraps the list of cache entries, but this might make it
      easier in the future to change the structure of the cache.
      2cce2cb8
    • Edsko de Vries's avatar
      Introduce structured type for specifying index · 99454f73
      Edsko de Vries authored
      In particular, distinguish between the repo-global index and a (sandbox-)local
      index.
      99454f73
  9. 09 Dec, 2015 1 commit
  10. 09 Oct, 2015 1 commit
    • Edward Z. Yang's avatar
      Implement ComponentId, replacing PackageKey and InstalledPackageId. · b083151f
      Edward Z. Yang authored
      
      
      Today in Cabal, when you build and install a package, it is
      uniquely identified using an InstalledPackageId which is computed
      using the ABI hash of the library that was installed.  There
      are few problems with doing it this way:
      
          - In a Nix-like world, we should instead uniquely identify
            build products by some sort of hash on the inputs to the
            compilation (source files, dependencies, flags).  The ABI
            hash doesn't capture any of this!
      
          - An InstalledPackageId suggests that we can uniquely identify
            build products by hashing the source and dependencies of
            a package as a whole.  But Cabal packages contain many components:
            a library, test suite, executables, etc.  Currently, when
            we say InstalledPackageId, we are really just talking about
            the dependencies of the library; however, this is unacceptable
            if a Cabal package can install multiple libraries; we need
            different identifiers for each.
      
          - We've also needed to compute another ID, which we've called
            the "package key", which is to be used for linker symbols
            and type equality GHC-side.  It is confusing what the distinction
            between this ID and InstalledPackageIds are; the main reason
            we needed another ID was because the package key was needed
            prior to compilation, whereas the ABI hash was only available
            afterwards.
      
      This patch replaces InstalledPackageId and PackageKey with a
      new identifier called ComponentId, which has the following
      properties:
      
          - It is computed per-component, and consists of a package
            name, package version, hash of the ComponentIds
            of the dependencies it is built against, and the name
            of the component.  For example, "foo-0.1-abcdef" continues
            to identify the library of package foo-0.1, but
            "foo-0.1-123455-foo.exe" would identify the executable,
            and "foo-0.1-abcdef-bar" would identify a private sub-library
            named bar.
      
          - It is passed to GHC to be used for linker symbols and
            type equality.  So as far as GHC is concerned, this is
            the end-all be-all identifier.
      
          - Cabal the library has a simple, default routine for computing
            a ComponentId which DOES NOT hash source code;
            in a later patch Duncan is working on, cabal-install can
            specify a more detailed ComponentId for a package
            to be built with.
      
      Here are some knock-on effects:
      
          - 'id' is a ComponentId
      
          - 'depends' is now a list of ComponentIds
      
          - New 'abi' field to record what the ABI of a unit is (as it is no longer
            computed by looking at the output of ghc --abi-hash).
      
          - The 'HasInstalledPackageId' typeclass is renamed to
            'HasComponentId'.
      
          - GHC 7.10 has explicit compatibility handling with
            a 'compatPackageKey' (an 'ComponentId') which is
            in a compatible format.  The value of this is read out
            from the 'key' field.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      b083151f
  11. 17 Sep, 2015 3 commits
  12. 30 Jul, 2015 1 commit
  13. 17 Jun, 2015 1 commit
  14. 31 May, 2015 1 commit
  15. 20 May, 2015 1 commit
    • Duncan Coutts's avatar
      Handle multiple preferred-versions in the index tarball better · 36265fb1
      Duncan Coutts authored
      The existing code supports reading multiple preferred-versions files in
      the 00-index.tar and merging them. However it doesn't do it quite right
      when the same file is updated, it merged them instead of the later one
      overriding the first.
      
      This should make no difference right now because the 00-index.tar
      typically only contains a single preferred-versions file, with no
      updates.
      36265fb1
  16. 28 Mar, 2015 1 commit
  17. 10 Mar, 2015 1 commit
  18. 06 Mar, 2015 1 commit
  19. 24 Oct, 2014 2 commits
  20. 11 Oct, 2014 2 commits
  21. 27 Aug, 2014 1 commit
  22. 25 Jul, 2014 1 commit
    • Mikhail Glushenkov's avatar
      Replace a '>=' comparison with a '>'. · 440fe65e
      Mikhail Glushenkov authored
      It looks like #1443 was actually fixed by the change from getModificationTime to
      getModTime (which has higher resolution). The change to '>=' was not needed
      because the code uses 'when', not 'unless'.
      
      Thanks to Nikita Karetnikov for the heads-up.
      440fe65e
  23. 27 Apr, 2014 2 commits
  24. 14 Apr, 2014 1 commit
  25. 19 Dec, 2013 2 commits
  26. 27 Aug, 2013 1 commit
  27. 25 Aug, 2013 1 commit
  28. 23 Aug, 2013 2 commits
  29. 09 May, 2013 1 commit