Changelog for stack-1.6.3

Changelog

v1.6.3

Enhancements:

In addition to supporting .tar.gz and .zip files as remote archives,
plain .tar files are now accepted too. This will additionally help with
cases where HTTP servers mistakenly set the transfer encoding to gzip. See
#3647.

v1.6.1.1

v1.6.1

Major changes:

Complete overhaul of how snapshots are defined, the packages and
extra-deps fields, and a number of related items. For full
details, please see
the writeup on these changes. PR #3249,
see the PR description for a number of related issues.

Upgraded to version 2.0 of the Cabal library.

Behavior changes:

The --install-ghc flag is now on by default. For example, if you
run stack build in a directory requiring a GHC that you do not
currently have, Stack will automatically download and install that
GHC. You can explicitly set install-ghc: false or pass the flag
--no-install-ghc to regain the previous behavior.

stack ghci no longer loads modules grouped by package. This is
always an improvement for plain ghci - it makes loading faster and
less noisy. For intero, this has the side-effect that it will no
longer load multiple packages that depend on TH loading relative
paths. TH relative paths will still work when loading a single
package into intero. See
#3309

Setting GHC options for a package via ghc-options: in your
stack.yaml will promote it to a local package, providing for more
consistency with flags and better reproducibility. See:
#849

The package-indices setting with Hackage no longer works with the
00-index.tar.gz tarball, but must use the 01-index.tar.gz file
to allow revised packages to be found.

Options passsed via --ghci-options are now passed to the end of the
invocation of ghci, instead of the middle. This allows using +RTS
without an accompanying -RTS.

When auto-detecting --ghc-build, tinfo6 is now preferred over
standard if both versions of libtinfo are installed

Addition of stack build --copy-compiler-tool, to allow tools like
intero to be installed globally for a particular compiler.
#2643

Stack will ask before saving hackage credentials to file. This new
prompt can be avoided by using the save-hackage-creds setting. Please
see #2159.

The GHCRTS environment variable will no longer be passed through to
every program stack runs. Instead, it will only be passed through
commands like exec, runghc, script, ghci, etc.
See #3444.

ghc-options: for specific packages will now come after the options
specified for all packages / particular sets of packages. See
#3573.

The pvp-bounds feature is no longer fully functional, due to some
issues with the Cabal library's printer. See
#3550.

Other enhancements:

The with-hpack configuration option specifies an Hpack executable to use
instead of the Hpack bundled with Stack. Please
see #3179.

It's now possible to skip tests and benchmarks using --skip
flag

GitSHA1 is now StaticSHA256 and is implemented using the StaticSize 64 ByteString for improved performance.
See #3006

Dependencies via HTTP(S) archives have been generalized to allow
local file path archives, as well as to support setting a
cryptographic hash (SHA256) of the contents for better
reproducibility.

Allow specifying --git-branch when upgrading

When running stack upgrade from a file which is different from the
default executable path (e.g., on POSIX systems,
~/.local/bin/stack), it will now additionally copy the new
executable over the currently running stack executable. If
permission is denied (such as in /usr/local/bin/stack), the user
will be prompted to try again using sudo. This is intended to
assist with the user experience when the PATH environment variable
has not been properly configured, see
#3232.

stack setup for ghcjs will now install alex and happy if
they are not present. See
#3109.

Added stack ghci --only-main flag, to skip loading / importing
all but main modules. See the ghci documentation page
for further info.

Allow GHC's colored output to show through. GHC colors output
starting with version 8.2.1, for older GHC this does nothing.
Sometimes GHC's heuristics would work fine even before this change,
for example in stack ghci, but this override's GHC's heuristics
when they're broken by our collecting and processing GHC's output.

Extended the ghc-options field to support $locals, $targets,
and $everything. See:
#3329

Avoid spurious rebuilds when using --file-watch by not watching files for
executable, test and benchmark components that aren't a target. See:
#3483.

Stack will now try to detect the width of the running terminal
(only on POSIX for the moment) and use that to better display
output messages. Work is ongoing, so some messages will not
be optimal yet. The terminal width can be overriden with the
new --terminal-width command-line option (this works even on
non-POSIX).

Passing non local packages as targets to stack ghci will now
cause them to be used as -package args along with package
hiding.

Detect when user changed .cabal file instead of package.yaml. This
was implemented upstream in hpack. See
#3383.

Automatically run autoreconf -i as necessary when a configure
script is missing. See
#3534

GHC bindists can now be identified by their SHA256 checksum in addition to
their SHA1 checksum, allowing for more security in download.

For filesystem setup-info paths, it's no longer assumed that the
directory is writable, instead a temp dir is used. See
#3188.

In some cases, Cabal does not realize that it needs to reconfigure, and must
be told to do so automatically. This would manifest as a "shadowed
dependency" error message. We now force a reconfigure whenever a dependency is
built, even if the package ID remained the same. See
#2781.

When --pvp-bounds is enabled for sdist or upload, internal
dependencies could cause errors when uploaded to hackage. This is
fixed, see #3290

Fixes a bug where nonexistent hackage versions would cause stack to
suggest the same package name, without giving version info. See
#3562

Fixes a bug that has existed since 1.5.0, where
stack setup --upgrade-cabal would say that Cabal is already the latest
version, when it wasn't.

Ensure that an extra-dep from a local directory is not treated as
a $locals for GHC options purposes. See
#3574.

Building all executables only happens once instead of every
time. See
#3229 for
more info.

1.5.1

Bug fixes:

Stack eagerly tries to parse all cabal files related to a
snapshot. Starting with Stackage Nightly 2017-07-31, snapshots are
using GHC 8.2.1, and the ghc.cabal file implicitly referenced uses
the (not yet supported) Cabal 2.0 file format. Future releases of
Stack will both be less eager about cabal file parsing and support
Cabal 2.0. This patch simply bypasses the error for invalid parsing.

1.5.0

Behavior changes:

stack profile and stack trace now add their extra RTS arguments for
benchmarks and tests to the beginning of the args, instead of the end.
See #2399

Support for Git-based indices has been removed.

Other enhancements:

stack setup allow to control options passed to ghcjs-boot with
--ghcjs-boot-options (one word at a time) and --[no-]ghcjs-boot-clean

stack setup now accepts a --install-cabal VERSION option which
will install a specific version of the Cabal library globally.

Updates to store-0.4.1, which has improved performance and better error
reporting for version tags. A side-effect of this is that all of
stack's binary caches will be invalidated.

stack solver will now warn about unexpected cabal-install versions.
See #3044

Upstream packages unpacked to a temp dir are now deleted as soon as
possible to avoid running out of space in /tmp.
See #3018

Add short synonyms for test-arguments and benchmark-arguments options.

Can now use relative paths for extra-include-dirs and extra-lib-dirs.
See #2830

Improved bash completion for many options, including --ghc-options,
--flag, targets, and project executables for exec.

--haddock-arguments is actually used now when haddock is invoked
during documentation generation.

--[no-]haddock-hyperlink-source flag added which allows toggling
of sources being included in Haddock output.
See #3099

stack ghci will now skip building all local targets, even if they have
downstream deps, as long as it's registered in the DB.

The pvp-bounds feature now supports adding -revision to the end of
each value, e.g. pvp-bounds: both-revision. This means that, when
uploading to Hackage, Stack will first upload your tarball with an
unmodified .cabal file, and then upload a cabal file revision with
the PVP bounds added. This can be useful—especially combined
with the
Stackage no-revisions feature—as
a method to ensure PVP compliance without having to proactively fix
bounds issues for Stackage maintenance.

Expose a save-hackage-creds configuration option

On GHC <= 7.8, filters out spurious linker warnings on windows
See #3127

Better error messages when creating or building packages which alias
wired-in packages. See
#3172.

When using Nix, nix-shell now depends always on git to prevent runtime errors
while fetching metadata

The stack unpack command now accepts a form where an explicit
Hackage revision hash is specified, e.g. stack unpack
foo-1.2.3@gitsha1:deadbeef. Note that this should be considered
experimental, Stack will likely move towards a different hash
format in the future.

Binary "stack upgrade" will now warn if the installed executable is not
on the PATH or shadowed by another entry.

A new command, script, has been added, intended to make the script
interpreter workflow more reliable, easier to use, and more
efficient. This command forces the user to provide a --resolver
value, ignores all config files for more reproducible results, and
optimizes the existing package check to make the common case of all
packages already being present much faster. This mode does require
that all packages be present in a snapshot, however.
#2805

Behavior changes:

The default package metadata backend has been changed from Git to
the 01-index.tar.gz file, from the hackage-security project. This is
intended to address some download speed issues from Github for
people in certain geographic regions. There is now full support for
checking out specific cabal file revisions from downloaded tarballs
as well. If you manually specify a package index with only a Git
URL, Git will still be used. See
#2780

When you provide the --resolver argument to the stack unpack
command, any packages passed in by name only will be looked up in
the given snapshot instead of taking the latest version. For
example, stack --resolver lts-7.14 unpack mtl will get version
2.2.1 of mtl, regardless of the latest version available in the
package indices. This will also force the same cabal file revision
to be used as is specified in the snapshot.

Unpacking via a package identifier (e.g. stack --resolver lts-7.14
unpack mtl-2.2.1) will ignore any settings in the snapshot and take
the most recent revision.

For backwards compatibility with tools relying on the presence of a
00-index.tar, Stack will copy the 01-index.tar file to
00-index.tar. Note, however, that these files are different; most
importantly, 00-index contains only the newest revisions of cabal
files, while 01-index contains all versions. You may still need to
update your tooling.

Passing --(no-)nix-* options now no longer implies --nix, except for
--nix-pure, so that the user preference whether or not to use Nix is
honored even in the presence of options that change the Nix behavior.

Other enhancements:

Internal cleanup: configuration types are now based much more on lenses

stack build and related commands now allow the user to disable debug symbol stripping
with new --no-strip, --no-library-stripping, and --no-executable-shipping flags,
closing #877.
Also turned error message for missing targets more readable (#2384)

stack haddock now shows index.html paths when documentation is already up to
date. Resolved #781

Respects the custom-setup field introduced in Cabal 1.24. This
supercedes any explicit-setup-deps settings in your stack.yaml
and trusts the package's .cabal file to explicitly state all its
dependencies.

If system package installation fails, get-stack.sh will fail as well. Also
shows warning suggesting to run apt-get update or similar, depending on the
OS.
(#2898)

When stack ghci is run with a config with no packages (e.g. global project),
it will now look for source files in the current work dir.
(#2878)

Bump to hpack 0.17.0 to allow custom-setup and !include "..." in package.yaml.

The script interpreter will now output error logging. In particular,
this means it will output info about plan construction errors.
(#2879)

stack ghci now takes --flag and --ghc-options again (inadverently
removed in 1.3.0).
(#2986)

stack exec now takes --rts-options which passes the given arguments inside of
+RTS ... args .. -RTS to the executable. This works around stack itself consuming
the RTS flags on Windows. (#2640)

Upgraded http-client-tls version, which now offers support for the
socks5:// and socks5h:// values in the http_proxy and https_proxy
environment variables.

Bug fixes:

Bump to hpack 0.16.0 to avoid character encoding issues when reading and
writing on non-UTF8 systems.

1.3.2

Correct the testing of whether a package database exists by checking
for the package.cache file itself instead of the containing
directory.

Revert a change in the previous release which made it impossible to
set local extra-dep packages as targets. This was overkill; we
really only wanted to disable their test suites, which was already
handled by a later
patch. #2849

1.3.0

Release notes:

For the next stack release after this one, we are planning
changes to our Linux releases, including dropping our Ubuntu,
Debian, CentOS, and Fedora package repositories and switching to
statically linked binaries. See
#2534.
Note that upgrading without a package manager has gotten easier
with new binary upgrade support in stack upgrade (see the Major
Changes section below for more information). In addition, the
get.haskellstack.org script no longer installs from Ubuntu,
Debian, CentOS, or Fedora package repositories. Instead it places
a generic binary in /usr/local/bin.

Major changes:

Stack will now always use its own GHC installation, even when a suitable GHC
installation is available on the PATH. To get the old behaviour, use
the --system-ghc flag or run stack config set system-ghc --global true.
Docker- and Nix-enabled projects continue to use the GHC installations
in their environment by default.

NB: Scripts that previously used stack in combination with a system GHC
installation should now include a stack setup line or use the --install-ghc
flag.
#2221

stack ghci now defaults to skipping the build of target packages, because
support has been added for invoking "initial build steps", which create
autogen files and run preprocessors. The --no-build flag is now deprecated
because it should no longer be necessary. See
#1364

Stack is now capable of doing binary upgrades instead of always
recompiling a new version from source. Running stack upgrade will
now default to downloading a binary version of Stack from the most
recent release, if one is available. See stack upgrade --help for
more options.
#1238

Behavior changes:

Passing --resolver X with a Stack command which forces creation of a global
project config, will pass resolver X into the initial config.
See #2579.

Switch the "Run from outside project" messages to debug-level, to
avoid spamming users in the normal case of non-project usage

If a remote package is specified (such as a Git repo) without an explicit
extra-dep setting, a warning is given to the user to provide one
explicitly.

Fix a long-standing performance regression where stack would parse the .dump-hi
files of the library components of local packages twice.
#2658

Fixed a regression in "stack ghci --no-load", where it would prompt for a main
module to load. #2603

Build Setup.hs files with the threaded RTS, mirroring the behavior of
cabal-install and enabling more complex build systems in those files.

Fixed a bug in passing along --ghc-options to ghcjs. They were being
provided as --ghc-options to Cabal, when it needs to be --ghcjs-options.
#2714

Launch Docker from the project root regardless of the working
directory Stack is invoked from. This means paths relative to the project root
(e.g. environment files) can be specified in stack.yaml's docker run-args.

1.2.0

Release notes:

On many Un*x systems, Stack can now be installed with a simple
one-liner:

wget -qO- https://get.haskellstack.org/ | sh

The fix for
#2175
entails that stack must perform a full clone of a large Git repo of
Hackage meta-information. The total download size is about 200 MB.
Please be aware of this when upgrading your stack installation.

If you use Mac OS X, you may want to delay upgrading to macOS Sierra as there
are reports of GHC panics when building some packages (including Stack
itself). See #2577

This version of Stack does not build on ARM or PowerPC systems (see
store#37). Please stay with
version 1.1.2 for now on those architectures. This will be rectified soon!

We are planning some changes to our Linux releases, including dropping our
Ubuntu, Debian, CentOS, and Fedora package repositories and switching to
statically linked binaries. We would value your feedback in
#2534.

The Linux gmp4 GHC bindist is no longer considered a full-fledged GHC
variant and can no longer be specified using the ghc-variant option,
and instead is treated more like a slightly different platform.

Other enhancements:

Use the store package for binary serialization of most caches.

Only require minor version match for Docker stack exe.
This way, we can make patch releases for version bounds and similar
build issues without needing to upload new binaries for Docker.

Stack/Nix: Passes the right ghc derivation as an argument to the shell.nix when a
custom shell.nix is used
See #2243

1.1.2

Extensible custom snapshots implemented. These allow you to define snapshots
which extend other snapshots. See
#863. Local file custom
snapshots can now be safely updated without changing their name. Remote custom
snapshots should still be treated as immutable.

Behavior changes:

stack path --compiler was added in the last release, to yield a path to the
compiler. Unfortunately, --compiler is a global option that is useful to use
with stack path. The same functionality is now provided by stack path
--compiler-exe. See
#2123

For packages specified in terms of a git or hg repo, the hash used in the
location has changed. This means that existing downloads from older stack
versions won't be used. This is a side-effect of the fix to
#2133

stack upgrade no longer pays attention to local stack.yaml files, just the
global config and CLI options.
#1392

stack ghci now uses :add instead of :load, making it potentially work
better with user scripts. See
#1888

Relative paths outside of source dir added via qAddDependentFile are now
checked for dirtiness. See
#1982

Signing: always use --with-fingerprints

1.1.0

Release notes:

Added Ubuntu 16.04 LTS (xenial) Apt repo.

No longer uploading new versions to Fedora 21 repo.

Behavior changes:

Snapshot packages are no longer built with executable profiling. See
#1179.

stack init now ignores symlinks when searching for cabal files. It also now
ignores any directory that begins with . (as well as dist dirs) - before
it would only ignore .git, .stack-work, and dist.

The stack executable is no longer built with -rtsopts. Before, when
-rtsopts was enabled, stack would process +RTS options even when intended
for some other program, such as when used with stack exec -- prog +RTS.
See #2022.

The stack path --ghc-paths option is deprecated and renamed to --programs.
--compiler is added, which points directly at the compiler used in
the current project. --compiler-bin points to the compiler's bin dir.

For consistency with the $STACK_ROOT environment variable, the
stack path --global-stack-root flag and the global-stack-root field
in the output of stack path are being deprecated and replaced with the
stack-root flag and output field.
Additionally, the stack root can now be specified via the
--stack-root command-line flag. See
#1148.

GPG signing of packages while uploading to Hackage is now the default. Use
upload --no-signature if you would rather not contribute your package
signature. If you don't yet have a GPG keyset, read this
blog post on GPG keys.
We can add a stack.yaml config setting to disable signing if some people
desire it. We hope that people will sign. Later we will be adding GPG
signature verification options.

stack build pkg-1.2.3 will now build even if the snapshot has a different
package version - it is treated as an extra-dep. stack build local-pkg-1.2.3
is an error even if the version number matches the local package
#2028.

Having a nix: section no longer implies enabling nix build. This allows the
user to globally configure whether nix is used (unless the project overrides
the default explicitly). See
#1924.

On each run, stack will test the stack root directory (~/.stack), and the
project and package work directories (.stack-work) for whether they are
owned by the current user and abort if they are not. This precaution can
be disabled with the --allow-different-user flag or allow-different-user
option in the global config (~/.stack/config.yaml).
#471

1.0.0

We're calling this version 1.0.0 in preparation for Stackage
LTS 4. Note, however, that this does not mean the code's API
will be stable as this is primarily an end-user tool.

Enhancements:

Added flag --profile flag: passed with stack build, it will
enable profiling, and for --bench and --test it will generate a
profiling report by passing +RTS -p to the executable(s). Great
for using like stack build --bench --profile (remember that
enabling profile will slow down your benchmarks by >4x). Run stack
build --bench again to disable the profiling and get proper speeds

Added flag --trace flag: just like --profile, it enables
profiling, but instead of generating a report for --bench and
--test, prints out a stack trace on exception. Great for using
like stack build --test --trace

0.1.10.1

0.1.10.0

Release notes:

The Stack home page is now at haskellstack.org,
which shows the documentation rendered by readthedocs.org. Note: this
has necessitated some changes to the links in the documentation's markdown
source code, so please check the links on the website before submitting a PR
to fix them.

The locations of the
Ubuntu
and
Debian
package repositories have changed to have correct URL semantics according to
Debian's guidelines
#1378. The old
locations will continue to work for some months, but we suggest that you
adjust your /etc/apt/sources.list.d/fpco.list to the new location to avoid
future disruption.

0.1.6.0

Major changes:

stack setup now supports building and booting GHCJS from source tarball.

On Windows, build directories no longer display "pretty" information
(like x86_64-windows/Cabal-1.22.4.0), but rather a hash of that
content. The reason is to avoid the 260 character path limitation on
Windows. See
#1027

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) while being either neutral or a minor slowdown for more common cases.

stack test --coverage now also generates a unified coverage report for multiple test-suites / packages. In the unified report, test-suites can contribute to the coverage of other packages.

Added --file-watch-poll flag for polling instead of using filesystem events (useful for running tests in a Docker container while modifying code in the host environment. When code is injected into the container via a volume, the container won't propagate filesystem events).

Give a preemptive error message when -prof is given as a GHC option #1015

Locking is now optional, and will be turned on by setting the STACK_LOCK environment variable to true#950

0.1.4.1

0.1.4.0

Major changes:

You now have more control over how GHC versions are matched, e.g. "use exactly this version," "use the specified minor version, but allow patches," or "use the given minor version or any later minor in the given major release." The default has switched from allowing newer later minor versions to a specific minor version allowing patches. For more information, see #736 and #784.

Support added for compiling with GHCJS

stack can now reuse prebuilt binaries between snapshots. That means that, if you build package foo in LTS-3.1, that binary version can be reused in LTS-3.2, assuming it uses the same dependencies and flags. #878

Other enhancements:

Added the --docker-env argument, to set environment variables in Docker container.