This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 17 Dec, 2015 2 commits
    • Edsko de Vries's avatar
      Change globalRepos to withGlobalRepos · a301b156
      Edsko de Vries authored
      In other words, give it a callback, changing the type from
      
          globalRepos :: GlobalFlags -> [Repo]
      
      to
      
          Verbosity -> GlobalFlags -> ([Repo] -> IO a) -> IO a
      
      This will be necessary for repositories that need to do some
      repository-specific initialization (even if we don't currently have any, we
      will soon). The Verbosity flag is not used yet, but will be.
      
      This just changes the type and deals with the fallout.
      a301b156
    • 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
  2. 16 Dec, 2015 2 commits
    • Edsko de Vries's avatar
      Extend repo config with security settings · 0d9226d6
      Edsko de Vries authored
      This extends `RemoteRepo` with new fields
      
      ``` haskell
      -- | Enable secure access to Hackage?
      remoteRepoSecure :: Bool,
      
      -- | Root key IDs (for bootstrapping)
      remoteRepoRootKeys :: [String],
      
      -- | Threshold for verification during bootstrapping
      remoteRepoKeyThreshold :: Int,
      ```
      
      and modifies the parser accordingly. This does not yet require a dependency on
      the security library.
      
      NOTE: We suggest to make the security functionality opt-in, rather than
      opt-out, for the first official release. Thus, the 'secure' field will be set
      to 'False' when initializing a `~/.cabal/config` file, and existing
      `~/.cabal/config` files will be interpreted as if they had `secure: False`.
      0d9226d6
    • Edsko de Vries's avatar
      Remove magic value from `globalCommand` · 7be7efdd
      Edsko de Vries authored
      In the definition of `globalCommand` we had
      
          (case showOrParseArgs of ShowArgs -> take 8; ParseArgs -> id) [..]
      
      the intention here is that the first 8 options will be shown when the user asks
      for `--help`, and the rest are not. However, this is rather error prone. If we
      forget to update that value when adding a new command line argument, we might
      either be wondering why the option isn't showing in the help text,
      or--worse--push another flag out of the help text without noticing.
      
      This commit changes this to
      
          args ShowArgs  = argsShown
          args ParseArgs = argsShown ++ argsNotShown
      
          argsShown    = [..]
          argsNotShown = [..]
      
      which is a lot more robust.
      7be7efdd
  3. 12 Nov, 2015 1 commit
  4. 26 Oct, 2015 1 commit
  5. 22 Oct, 2015 1 commit
  6. 17 Oct, 2015 1 commit
  7. 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
  8. 10 Sep, 2015 1 commit
  9. 31 Jul, 2015 1 commit
  10. 06 Jul, 2015 1 commit
    • Duncan Coutts's avatar
      Make the profiling detail level configurable with a flag · 5a6699ef
      Duncan Coutts authored
      New flags: --profiling-detail and --library-profiling-detail.
      When profiling is enabled (by the existing flags) then these flags
      are taken into account to set the profiling detail level.
      
      The levels are:
       none
       default
       exported-functions
       toplevel-functions
       all-functions
      
      The default value for ghc for libraries is exported-functions and
      for exes is toplevel-functions.
      
      On GHC these levels correspond to the -fprof-auto* flags. The
      ghc-prof-options will override this (just because it's passed to
      ghc at the end).
      5a6699ef
  11. 29 Jun, 2015 3 commits
    • Duncan Coutts's avatar
      Change the logic for automatically upgrading to HTTPS · 36e9e622
      Duncan Coutts authored
      The initial patch would always try to use HTTPS, even when the repo
      specified to use HTTP. This works for the central community hackage
      but obviously does not work in general.
      
      The new logic is that we always follow what is specified for the
      remote repo in the config, except for built-in known repos (currently
      just the central community hackage) where we mark them as also
      supporting https. For upload when uploading to such a marked repo
      then we will try https and will complain if the plain-http impl was
      selected automatically (but it's ok if selected manually).
      
      This patch also changes things so that for http urls on download, we
      stick to the builtin http impl by default, and only use the external
      ones if https support is required (i.e. because the repo was
      configured to use an https url)
      36e9e622
    • Duncan Coutts's avatar
      Further work, refactoring and reformatting of new http transport code · 22f05445
      Duncan Coutts authored
      Move utils into other Util modules.
      Reformat all code to 80 cols.
      Reorder code and add more comments.
      Use long form style program args, e.g. --silent rather than -s
      Finish implementation of form upload with wget
      Fix reporting of server error messages for upload (curl & builtin)
      Implement collecting of ETags for curl and wget.
      Fix wget for case of 304 not modified response (wget uses exit code 8).
      Rework transport configuration phase.
      22f05445
    • U-CIQDEV\gbazerman's avatar
      Implement HTTPS support using external curl, wget and powershell · b780cc77
      U-CIQDEV\gbazerman authored
      Supports both uploading and downloading.
      Basic built-in HTTP is still supported.
      b780cc77
  12. 02 Jun, 2015 1 commit
    • tibbe's avatar
      Allow using cabal program itself as the external setup method · 03b02fb6
      tibbe authored
      This fixes issues when the version of Cabal that cabal-install was built
      against differs from the one registered in the local package DB. Normally
      we compile an external setup against the local Cabal library, which could
      lead to failures or inconsistent results compared to using the internal
      method.
      
      This fixes #2438 and fixes #1938.
      03b02fb6
  13. 30 May, 2015 1 commit
  14. 05 May, 2015 1 commit
  15. 29 Apr, 2015 1 commit
  16. 28 Apr, 2015 1 commit
  17. 05 Apr, 2015 1 commit
  18. 30 Mar, 2015 1 commit
  19. 28 Mar, 2015 1 commit
  20. 19 Mar, 2015 1 commit
  21. 06 Mar, 2015 1 commit
  22. 04 Mar, 2015 1 commit
  23. 25 Feb, 2015 1 commit
  24. 16 Feb, 2015 2 commits
  25. 15 Feb, 2015 2 commits
  26. 18 Jan, 2015 2 commits
  27. 15 Dec, 2014 1 commit
  28. 12 Dec, 2014 2 commits
  29. 07 Dec, 2014 4 commits