Merge branch 'master' into sig-sign-sdist-and-upload-sign

* master: (59 commits) Ignore global database when copying precompiled packages #1146 Revert an unneeded change to 'runAndLog' Remove old GHCJS unpack directory if it exists Allow "stack setup ghcjs-0.1.0.20150924_ghc-7.10.2" Properly unzip GHCJS on windows (stack setup) Consider user-specified package flags in stack solver #1071 Fix a warning Colored build status in filewatch mode Add NixOS to 'How to install'. Include NixOS information #1118 Style improvements for Docker compatibility check Fix `awaiting pr` label link Fix GHC 7.8 build Docker: check host's stack compatibility by attempting to run in container and caching the result (#974) Fix formatting in `explicit-setup-deps` section Provide more information about changed files Compile custom Setup.hs instead of interpreting them (fixes #1041) Detect when hpc report gives trivial 100% #1009 Unified coverage report #579 Recommend extra-dep in yaml_configuration.yml ...
commercialhaskell · Oct 13, 2015 · 3da50d0 · 3da50d0
2 parents c0554da + 6b8fd22
commit 3da50d0
Show file tree

Hide file tree

Showing 37 changed files with 1,416 additions and 534 deletions.
diff --git a/ChangeLog.md b/ChangeLog.md
@@ -24,6 +24,13 @@ Other enhancements:
 * Typing enter during --file-watch triggers a rebuild [#1023](https://github.com/commercialhaskell/stack/pull/1023)
 * Use Haddock's `--hyperlinked-source` (crosslinked source), if available [#1070](https://github.com/commercialhaskell/stack/pull/1070)
 * Use Stack-installed GHCs for `stack init --solver` [#1072](https://github.com/commercialhaskell/stack/issues/1072)
+* New experimental `stack query` command [#1087](https://github.com/commercialhaskell/stack/issues/1087)
+* By default, stack no longer rebuilds a package due to GHC options changes. This behavior can be tweaked with the `rebuild-ghc-options` setting. [#1089](https://github.com/commercialhaskell/stack/issues/1089)
+* By default, ghc-options are applied to all local packages, not just targets. This behavior can be tweaked with the `apply-ghc-options` setting. [#1089](https://github.com/commercialhaskell/stack/issues/1089)
+* Docker: download or override location of stack executable to re-run in container [#974](https://github.com/commercialhaskell/stack/issues/974)
+* Docker: when Docker Engine is remote, don't run containerized processes as host's UID/GID [#194](https://github.com/commercialhaskell/stack/issues/194)
+* Docker: `set-user` option to enable/disable running containerized processes as host's UID/GID [#194](https://github.com/commercialhaskell/stack/issues/194)
+* Custom Setup.hs files are now precompiled instead of interpreted. This should be a major performance win for certain edge cases (biggest example: [building Cabal itself](https://github.com/commercialhaskell/stack/issues/1041)) while being either neutral or a minor slowdown for more common cases.
 
 Bug fixes:
 
@@ -32,6 +39,11 @@ Bug fixes:
 * Fix quoting of output failed command line arguments
 * Mark executable-only packages as installed when copied from cache [#1043](https://github.com/commercialhaskell/stack/pull/1043)
 * Canonicalize temporary directory paths [#1047](https://github.com/commercialhaskell/stack/pull/1047)
+* Put code page fix inside the build function itself [#1066](https://github.com/commercialhaskell/stack/issues/1066)
+* Add `explicit-setup-deps` option [#1110](https://github.com/commercialhaskell/stack/issues/1110), and change the default to the old behavior of using any package in the global and snapshot database [#1025](https://github.com/commercialhaskell/stack/issues/1025)
+* Precompiled cache checks full package IDs on Cabal < 1.22 [#1103](https://github.com/commercialhaskell/stack/issues/1103)
+* Pass -package-id to ghci [#867](https://github.com/commercialhaskell/stack/issues/867)
+* Ignore global packages when copying precompiled packages [#1146](https://github.com/commercialhaskell/stack/issues/1146)
 
 ## 0.1.5.0
 

diff --git a/README.md b/README.md
@@ -28,6 +28,7 @@ Downloads are available by operating system:
 * [CentOS / Red Hat / Amazon Linux](doc/install_and_upgrade.md#centos--red-hat--amazon-linux)
 * [Fedora](doc/install_and_upgrade.md#fedora)
 * [Arch Linux](doc/install_and_upgrade.md#arch-linux)
+* [NixOS](doc/install_and_upgrade.md#nixos)
 * [Linux (general)](doc/install_and_upgrade.md#linux)
 
 [Upgrade instructions](doc/install_and_upgrade.md#upgrade)
@@ -37,31 +38,79 @@ constraint to work around a
 [Cabal issue](https://github.com/haskell/cabal/issues/2759): `cabal install
 --constraint 'mono-traversable >= 0.9' stack`.
 
-#### How to use
+#### Quick Start Guide
 
-Go into a Haskell project directory and run `stack build`. If everything is
-already configured, this will:
+First you need to [install it (see previous section)](#how-to-install).
 
-* Download the package index.
-* Download and install all necessary dependencies for the project.
-* Build and install the project.
+##### Start your new project:
 
-You may be prompted to run some of the following along the way:
+~~~ {.bash}
+stack new my-project
+cd my-project
+stack setup
+stack build
+stack exec my-project-exe
+~~~
+
+- The `stack new` command will create a new directory containing all
+the needed files to start a project correctly.
+- The `stack setup` will download the compiler if necessary in an isolated
+  location (default `~/.stack`) that won't interfere with any system-level
+  installations. (For information on installation paths, please use the `stack
+  path` command.).
+- The `stack build` command will build the minimal project.
+- `stack exec my-project-exe` will execute the command.
+- If you just want to install an executable using stack, then all you have to do
+is`stack install <package-name>`.
 
-* `stack new` to create a brand new project.
-* `stack init` to create a stack configuration file for an existing project.
-  stack will figure out what Stackage release (LTS or nightly) is appropriate
-  for the dependencies.
-* `stack setup` to download and install the correct GHC version in an
-  isolated location (default `~/.stack`) that won't interfere with any
-  system-level installations. (For information on installation paths,
-  please use the `stack path` command.)
+If you want to launch a REPL:
+
+~~~ {.bash}
+stack ghci
+~~~
 
-If you just want to install an executable using stack, then all you have
-to do is `stack install <package-name>`.
 
 Run `stack` for a complete list of commands.
 
+##### Workflow
+
+The `stack new` command should have created the following files:
+
+~~~
+.
+├── LICENSE
+├── Setup.hs
+├── app
+│   └── Main.hs
+├── my-project.cabal
+├── src
+│   └── Lib.hs
+├── stack.yaml
+└── test
+    └── Spec.hs
+
+    3 directories, 7 files
+~~~
+
+So to manage your library:
+
+1. Edit files in the `src/` directory.
+
+The `app` directory should preferably contains only files related to
+executables.
+
+2. If you need to include another library (for example the package [`text`](https://hackage.haskell.org/package/text):
+
+   - Add the package `text` to the file `my-project.cabal`
+     in the section `build-depends: ...`.
+   - run `stack build` another time
+
+3. If you get an error that tells you your package isn't in the LTS.
+   Just try to add a new version in the `stack.yaml` file in the `extra-deps` section.
+
+It was a really fast introduction on how to start to code in Haskell using `stack`.
+If you want to go further, we highly recommend you to read the [`stack` guide](https://github.com/commercialhaskell/stack/blob/master/doc/GUIDE.md).
+
 #### How to contribute
 
 This assumes that you have already installed a version of stack, and have `git`
@@ -75,7 +124,7 @@ installed.
 4. Once `stack` finishes building, check the stack version with
    `stack --version`. Make sure the version is the latest.
 5. Look for issues tagged with
-   [`newcomer` and `awaiting-pr` labels](https://github.com/commercialhaskell/stack/issues?q=is%3Aopen+is%3Aissue+label%3Anewcomer+label%3Aawaiting-pr)
+   [`newcomer` and `awaiting-pr` labels](https://github.com/commercialhaskell/stack/issues?q=is%3Aopen+is%3Aissue+label%3Anewcomer+label%3A%22awaiting+pr%22)
 
 Build from source as a one-liner:
 

diff --git a/doc/GUIDE.md b/doc/GUIDE.md
@@ -1712,3 +1712,25 @@ users. Here's a quick rundown:
   but it can be useful if you're trying to test a specific bugfix.
 * `stack list-dependencies` lists all of the packages and versions used for a
   project
+
+## Debugging
+
+The following command installs with profiling enabled:
+
+`stack install --enable-executable-profiling --enable-library-profiling
+--ghc-options="-rtsopts"`
+
+This command will allow you to use various tools to profile the time,
+allocation, heap, and more of a program. The `-prof` GHC option is unnecessary
+and will result in a warning. Additional compilation options can be added to
+`--ghc-options` if needed. To see a general overview of the time and allocation
+of a program called `main` compiled with the above command, you can run
+
+`./main +RTS -p`
+
+to generate a `main.prof` file containing the requested profiling information.
+For more commands and uses, see [the official GHC chapter on
+profiling](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html),
+[the Haskell wiki](https://wiki.haskell.org/How_to_profile_a_Haskell_program),
+and [the chapter on profiling in Real World
+Haskell](http://book.realworldhaskell.org/read/profiling-and-optimization.html).
diff --git a/doc/docker_integration.md b/doc/docker_integration.md
@@ -184,6 +184,25 @@ otherwise noted.
       # all users share a single database.
       database-path: "~/.stack/docker.db"
 
+      # Location of a Docker container-compatible 'stack' executable with the
+      # matching version. This executable must be built on linux-x86_64 and
+      # statically linked.
+      # Valid values are:
+      #   host: use the host's executable.  This is the default when the host's
+      #     executable is known to work (e.g., from official linux-x86_64 bindist)
+      #   download: download a compatible executable matching the host's version.
+      #     This is the default when the host's executable is not known to work
+      #   image: use the 'stack' executable baked into the image.  The version
+      #     must match the host's version
+      #   /path/to/stack: path on the host's local filesystem
+      stack-exe: host
+
+      # If true (the default when using the local Docker Engine), run processes
+      # in the Docker container as the same UID/GID as the host.  The ensures
+      # that files written by the container are owned by you on the host.
+      # When the Docker Engine is remote (accessed by tcp), defaults to false.
+      set-user: true
+
 Image Repositories
 -------------------------------------------------------------------------------
 
@@ -223,7 +242,9 @@ a 64-bit kernel. If you do not already have one, we suggest Ubuntu 14.04
 
 While Docker does support non-Linux operating systems through the `boot2docker`
 VM, there are issues with host volume mounting that prevent stack from being
-usable in this configuration.
+usable in this configuration. See
+[#194](https://github.com/commercialhaskell/stack/issues/194) for details and
+workarounds.
 
 ### Docker
 
@@ -424,4 +445,4 @@ This does require the private registry to be available over plaintext HTTP.
 
 See
 [Docker daemon insecure registries documentation](https://docs.docker.com/reference/commandline/cli/#insecure-registries)
-for details.
+for details.
diff --git a/doc/install_and_upgrade.md b/doc/install_and_upgrade.md
@@ -4,6 +4,8 @@ Binary packages are signed with this [signing key](SIGNING_KEY.md).
 
 ## Windows
 
+*Note*: Due to specific Windows limitations, [some temporary workarounds](https://www.fpcomplete.com/blog/2015/08/stack-ghc-windows) may be required. It is strongly advised to set your `STACK_ROOT` environment variable similarly to your root (e.g., `set STACK_ROOT=c:\stack_root`) *before* running `stack`.
+
 * Download [the latest release](https://github.com/commercialhaskell/stack/releases/latest). Note: while generally i386/32-bit GHC is better tested on Windows, there are reports that recent versions of Windows only work with the 64-bit version of stack (see [issue #393](https://github.com/commercialhaskell/stack/issues/393)).
 * Unpack the archive and place `stack.exe` somewhere on your `%PATH%` (see [Path section below](#path)) and you can then run `stack` on the command line.
 * Now you can run `stack` from the terminal.
@@ -28,6 +30,10 @@ We generally test on the current version of OS X, but stack is known to work on
 
 2. Add the appropriate source repository:
 
+    * Ubuntu 15.10 (amd64):
+
+        echo 'deb http://download.fpcomplete.com/ubuntu/wily stable main'|sudo tee /etc/apt/sources.list.d/fpco.list
+
     * Ubuntu 15.04 (amd64):
 
             echo 'deb http://download.fpcomplete.com/ubuntu/vivid stable main'|sudo tee /etc/apt/sources.list.d/fpco.list
@@ -148,6 +154,10 @@ Alternatively, the package can be built from source as follows.
 
          nix-env -i -f shell.nix
 
+For more information on using Stack together with Nix, please see [the NixOS
+manual section on
+Stack](http://nixos.org/nixpkgs/manual/#using-stack-together-with-nix).
+
 ## Linux
 
 (64-bit and 32-bit options available)
@@ -173,4 +183,4 @@ There are essentially three different approaches to upgrade:
 
 * If you're using a package manager (e.g., the Ubuntu debs listed above) and are happy with sticking with the officially released binaries, simply follow your normal package manager strategies for upgrading (e.g. `apt-get update && apt-get upgrade`).
 * If you're not using a package manager but want to stick with the official binaries (such as on Windows or Mac), you'll need to manually follow the steps above to download the newest binaries from the release page and replace the old binary.
-* The `stack` tool itself ships with an `upgrade` command, which will build `stack` from source and install it to the default install path (see the previous section). You can use `stack upgrade` to get the latest official release, and `stack upgrade --git` to install from Git and leave on the bleeding edge. If you follow this, make sure that this directory is on your `PATH` and takes precedence over the system installed `stack`. For more information, see [this discussion](https://github.com/commercialhaskell/stack/issues/237#issuecomment-126793301).
+* The `stack` tool itself ships with an `upgrade` command, which will build `stack` from source and install it to the default install path (see the previous section). You can use `stack upgrade` to get the latest official release, and `stack upgrade --git` to install from Git and live on the bleeding edge. If you follow this, make sure that this directory is on your `PATH` and takes precedence over the system installed `stack`. For more information, see [this discussion](https://github.com/commercialhaskell/stack/issues/237#issuecomment-126793301).
diff --git a/doc/yaml_configuration.md b/doc/yaml_configuration.md
@@ -46,16 +46,15 @@ settings:
 * A list of subdirectories to build (useful for mega-repos like
 [wai](https://github.com/yesodweb/wai/) or
 [digestive-functors](https://github.com/jaspervdj/digestive-functors))
-* Whether a package should be treated as a dependency, in which case it will only be built if demanded by a non-dependency, and its test suites and benchmarks will not be run. This is useful for tweaking an upstream package.
-    * The current name for this is `valid-wanted`, which when `false` means "treat as a dependency." That's a confusing name choice, and therefore we're switching it to be `extra-dep: true` to mean "treat as dependency." You'll get a deprecation warning once that new naming is release.
+* Whether a package should be treated as a dependency: a package marked `extra-dep: true` will only be built if demanded by a non-dependency, and its test suites and benchmarks will not be run. This is useful for tweaking upstream packages.
 
 To tie this all together, here's an example of the different settings:
 
 ```yaml
 packages:
 - local-package
 - location: vendor/binary
-  valid-wanted: false
+  extra-dep: true
 - location:
     git: [email protected]:yesodweb/wai
     commit: 2f8a8e1b771829f4a8a77c0111352ce45a14c30f
@@ -291,3 +290,59 @@ pvp-bounds: none
 ```
 
 For more information, see [the announcement blog post](https://www.fpcomplete.com/blog/2015/09/stack-pvp).
+
+### modify-code-page
+
+(Since 0.1.6)
+
+Modify the code page for UTF-8 output when running on Windows. Default behavior
+is to modify.
+
+```yaml
+modify-code-page: false
+```
+
+### explicit-setup-deps
+
+(Since 0.1.6)
+
+Decide whether a custom `Setup.hs` script should be run with an explicit list
+of dependencies based on the dependencies of the package itself, or simply
+provided the global package database. This option is most often needed when
+overriding packages in the global database, see [issue #1110](https://github.com/commercialhaskell/stack/issues/1110).
+
+Setting the list explicitly can help when a Setup.hs depends on packages in the
+local package database. For more information on that case, see [issue #897](https://github.com/commercialhaskell/stack/issues/897).
+
+Note that in the future, this should all disappear once Cabal provides full
+support for explicit Setup.hs dependencies.
+
+```yaml
+explicit-setup-deps:
+    "*": true # change the default
+    entropy: false # override the new default for one package
+```
+
+### rebuild-ghc-options
+
+(Since 0.1.6)
+
+Should we rebuild a package when its GHC options change? Before 0.1.6, this was a non-configurable true. However, in most cases, the flag is used to affect optimization levels and warning behavior, for which GHC itself doesn't actually recompile the modules anyway. Therefore, the new behavior is to not recompile on an options change, but this behavior can be changed back with the following:
+
+```yaml
+rebuild-ghc-options: true
+```
+
+### apply-ghc-options
+
+(Since 0.1.6)
+
+Which packages do ghc-options on the command line get applied to? Before 0.1.6, the default value was `targets`
+
+```yaml
+apply-ghc-options: locals # all local packages, the default
+# apply-ghc-options: targets # all local packages that are targets
+# apply-ghc-options: everything # applied even to snapshot and extra-deps
+```
+
+Note that `everything` is a slightly dangerous value, as it can break invariants about your snapshot database.
diff --git a/etc/scripts/release.hs b/etc/scripts/release.hs
@@ -436,7 +436,8 @@ rules global@Global{..} args = do
         [ ("12.04", "precise")
         , ("14.04", "trusty")
         , ("14.10", "utopic")
-        , ("15.04", "vivid") ]
+        , ("15.04", "vivid")
+        , ("15.10", "wily") ]
     debianVersions =
         [ ("7", "wheezy")
         , ("8", "jessie") ]

diff --git a/src/Options/Applicative/Builder/Extra.hs b/src/Options/Applicative/Builder/Extra.hs
@@ -80,9 +80,9 @@ enableDisableFlagsNoDefault' enabledValue disabledValue maybeHideValue name help
 -- To actually show have that help appear, use 'execExtraHelp' before executing the main parser.
 extraHelpOption :: String -> String -> String -> Parser (a -> a)
 extraHelpOption progName fakeName helpName =
-    infoOption (optDesc ++ ".") (long helpName <> hidden <> internal) <*>
-    infoOption (optDesc ++ ".") (long fakeName <> help optDesc)
-  where optDesc = concat ["Run '", takeBaseName progName, " --", helpName, "' for details"]
+    infoOption (optDesc' ++ ".") (long helpName <> hidden <> internal) <*>
+    infoOption (optDesc' ++ ".") (long fakeName <> help optDesc')
+  where optDesc' = concat ["Run '", takeBaseName progName, " --", helpName, "' for details"]
 
 -- | Display extra help if extea help option passed in arguments.
 -- Since optparse-applicative doesn't allow an arbirary IO action for an 'abortOption', this