This project is mirrored from Pull mirroring updated .
  1. 06 Dec, 2016 1 commit
  2. 08 Oct, 2016 1 commit
  3. 29 Sep, 2016 1 commit
  4. 11 Sep, 2016 1 commit
  5. 08 Sep, 2016 2 commits
  6. 08 Jun, 2016 1 commit
  7. 03 May, 2016 1 commit
  8. 23 Apr, 2016 6 commits
  9. 19 Apr, 2016 2 commits
  10. 14 Apr, 2016 3 commits
  11. 10 Apr, 2016 3 commits
    • Duncan Coutts's avatar
      Add the new configure, build and repl commands · ed96a17d
      Duncan Coutts authored
      The three commands are all implemeted in terms of the planning and
      execution infrastracture added previously. The orchestration of that
      infrastructure is shared between the commands in another module.
      Also add a new CLI target parsing/recognising/disambiguating module,
      similar to the one in the Cabal lib used for the 'build' command, but
      extended to cover multiple packages in a project rather than just
      components within a package.
    • Duncan Coutts's avatar
      Maintain a plan.json file for external tools · fd7640e2
      Duncan Coutts authored
      This is (mostly) hvr's code.
      It produces an external representation of the elaborated install plan.
      The intention is for it to be used by external tools, editors etc, to
      find out relevant details of the project and package configuration and
      environment. It is updated whenever the elaborated install plan
      changes, so it always reflects the current state.
      Currently it only includes a modest subset of the details from the
      elaborated install plan, but the goal is to include all relevant details
      in a mostly-stable JSON format.
      Currently it's based on the elaborated install plan prior to improving
      the plan with packages from the store, but ultimately it will need to
      include information from both before and after the 'improvement' phase.
    • Duncan Coutts's avatar
      Split the ProjectPlanning types out into another module · f860cf98
      Duncan Coutts authored
      Not needed immediately, but we'll need it eventually to avoid import
      cycles later. No other changes, just moving things around and pruning
      imports and language extensions.
  12. 05 Apr, 2016 1 commit
  13. 25 Mar, 2016 1 commit
    • Duncan Coutts's avatar
      Extend file globs and file glob monitors · f6c1e71c
      Duncan Coutts authored
      File globs can now be absolute, e.g. starting with / or c:\
      Also allow homedir relative, ie ~/
      Globs can also have a trailing slash, in which case they only match
      directories, not files.
      Previously whether globs could match dirs was not totally consistent.
      The matchFileGlob would match dirs, but the file monitor globs would
      not. The file monitor globs can now match dirs (or with a trailing
      slash, only match dirs). File monitors now also detect changes in the
      file type, ie switching from file to dir or the other way around.
      The file monitor are now pretty consistent between single file monitors
      and globs monitors. They now have equivalent capabilities and share
      code. For a single file or for a glob we can now control what we
      monitor if the path is a file or a dir. In both cases we can monitor
      mere existence, non-existence or modification time. For files we can
      additionally monitor content hash.
      File monitors now also detect changes in the file type, ie switching
      from file to dir or the other way around.
      New tests cover all these new file monitor cases. There are also new
      tests for glob syntax, covering printing/parsing round trips.
  14. 24 Mar, 2016 2 commits
    • Duncan Coutts's avatar
      Add new style project building · 300d9bad
      Duncan Coutts authored
      This stage takes the ElaboratedInstallPlan and executes it. It does it
      in two passes.
      The first pass is the "dry run" pass where we work out which packages
      and components within packages we actually need to build. If we are in
      fact in --dry-run mode then of course this is the only pass we run, we
      have enough info after this to accurately report on what we would do.
      The first pass does the file monitor change stuff, which checks if
      package config has changed and probes for package file changes. Based on
      this we make a note of which phase of the build we would start at, up to
      and including skipping building that package entirely. In the latter
      case we replace the Configured package by a corresponding Installed
      The first pass also prunes the ElaboratedInstallPlan based on the
      targets that the user actually wants to build. For example we solve and
      plan on the basis that the user might want to run the test suites or
      benchmarks, but that doesn't mean we want to build them all the time
      (they'll usually pull in additional deps). So there's a moderately
      complex pass where we keep just the packages and components that are
      needed to build the target components.
      The first pass is moderately complicated but it makes no state changes
      and just returns the updated ElaboratedInstallPlan, so it should make
      things easier to debug.
      The second phase has very little logic it just does what its told based
      on all the earlier passes. For each package the dry run pass has worked
      out which build step to start with, e.g. downloading, configuring or
      The major cases the build phase has to deal with are packages that will
      be built and installed to the store, vs packages that are local and so
      are built inplace. It is only the latter that need all the complex
      rebuild checking. In both cases all the "setup $cmd" flags are
      calculated by the planning phase and we just do as we're told.
    • Duncan Coutts's avatar
      Add new style project planning · 2d065c8c
      Duncan Coutts authored
      This implements the planning phase of the new nix-style package build and
      install system. In particular it includes the calculation of the
      nix-style package ids by hashing all the package configuration.
      Project planning is separated from project building.
      The planning phase starts with finding the packages in the project and
      then solving. We solve without looking at the installed packages in the
      store. This makes everything more deterministic. The only installed
      packages the solver looks at are the globally installed ones. This
      approach also means we don't have any need of solver options like
      --reinstall or --avoid-reinstalls etc.
      The bulk of the planning phase is elaboration. We take the project
      configuration and the solver's InstallPlan and elaborate the latter into
      an ElaboratedInstallPlan. This is intended to contain all the details
      needed for the build phase. For example all the "setup" command flags
      are calculated directly from the elaborated plan.
      The building phase is then intended to be much simpler and free of much
      logic or policy. All of the complicated logic and policy is supposed to
      be in the planning phase. This should also make things a lot easier to
      debug, we can look at the plan we calculate and see if we're producing
      the right build instructions, rather than debugging based on the actions
      we end up executing.
      Doing all the planning up front is also crucial to calculating nix-style
      package hashes. This means we have the package ids up front. This then
      allows us to have another up-front phase where we improve the plan by
      replacing source packages with installed packages from the store.
      All of this stuff is done in the Rebuild monad, with a few levels of
      caches, so most of the time we can avoid recomputing the plan. In
      particular we want to avoid re-running the solver unless we have to.
      There are still quite a number of TODOs, which are categorised.
  15. 18 Mar, 2016 2 commits
  16. 13 Mar, 2016 3 commits
    • Duncan Coutts's avatar
      Add project config round trip QC tests · e36c0e7e
      Duncan Coutts authored
      Two kinds of round-trip test:
       * type conversion ProjectConfig -> LegcyProjectConfig and back
       * ProjectConfig -> print -> parse
      The latter goes out to the config file format and back.
      These tests uncovered a number of issues in our general config code.
    • Duncan Coutts's avatar
      New module for new style project configuration files · 324b3240
      Duncan Coutts authored
      This defines the new cabal.project files and introduces the notion of a
      project root (and the logic for finding it). Also has support for
      implicit projects when no cabal.project file is defined.
      Supports both reading and writing project files or fragments. The
      printing & parsing round trips correctly. QC tests to follow.
      This is a key part of the new nix-local-build branch approach, based
      around projects with clear configuration state held in a project file
      (or extra files).
      This has support for file and dirs as packages within a project,
      including by glob. It supports both globs that much match a target, and
      optional globs that are allowed to match nothing. It has partial support
      for local tarball, remote http tarball and remote source repo packages.
    • Duncan Coutts's avatar
      Add new DistDirLayout module · 7907a55c
      Duncan Coutts authored
      This describes in one place the layout of the new dist dir, as used by
      the nix-local-build branch. Also a similar approach to describing the
      layout of the user-wide cabal directory.
      The idea is that this centralises the description and makes it easier
      to change and handle systematically (e.g. we have problems currently
      with some user-wide files not being reolocatable).
  17. 03 Mar, 2016 2 commits
  18. 22 Feb, 2016 1 commit
  19. 19 Feb, 2016 1 commit
  20. 16 Feb, 2016 2 commits
  21. 13 Feb, 2016 1 commit
  22. 11 Feb, 2016 1 commit
  23. 10 Feb, 2016 1 commit