I'm trying to separate the stages of building my package and its dependencies in a sequence of uses of stack build but have become a bit disoriented by all the combinations of flags that seem relevant. My goal is to separately:
Build package dependencies only
Build testing dependencies only
Build the package, only
Run tests (with everything already built)
stack --resolver XXX build --no-run-tests--no-run-benchmarks --only-dependencies
stack --resolver XXX build --no-run-tests --no-run-benchmarks
stack --resolver XXX build --no-run-tests --no-run-benchmarks --test --bench
stack --resolver XXX build --test --no-run-benchmarks
Which isn't quite the right order and does't feel quite right. I'd also ideally like to have additional steps for documentation:
Build package dependencies only
Build testing dependencies only
Build Haddock dependencies only
Build the package, only
Run tests (with everything already built)
Build Haddock, with doctests
What sequence of commands and combinations of flags would accomplish these steps?
Related
I'm now learning hakyll static site generator with stack.
When I execute stack build in the directory of my Hakyll site to rebuild site.hs, stack also rebuilds and copy/register dependencies each time, as shown below:
$ stack --version
Version 1.6.5, Git revision 24ab0d6ff07f28276e082c3ce74dfdeb1a2ca9e9 (5514 commits) x86_64 hpack-0.20.0
$ grep -Ev '^[[:space:]]*#' stack.yaml | uniq
resolver: lts-11.4
packages:
- .
$ stack build
haddock-library-1.4.5: configure
haddock-library-1.4.5: build
haddock-library-1.4.5: copy/register
pandoc-2.1.2: configure
pandoc-2.1.2: build
pandoc-2.1.2: copy/register
pandoc-citeproc-0.14.3: configure
pandoc-citeproc-0.14.3: build
pandoc-citeproc-0.14.3: copy/register
hakyll-4.12.1.0: configure
hakyll-4.12.1.0: build
hakyll-4.12.1.0: copy/register
... and site.hs.compilation ...
This is odd to me, because I have never changed those packages.
The rebuild takes quite long even for very small changes on site.hs.
Why does stack rebuild those packages? And is there any way to reduce this rebuild time?
Thank you.
There is a discussion of this here https://github.com/commercialhaskell/stack/issues/3899 . It's a known issue triggered by newer versions of haddock using sub-libraries. There's a PR open fixing the issue, but it hasn't been merged yet.
How can I use stack to build and test a package against multiple resolvers?
Set the resolver from the command line, overriding whatever is in stack.yaml:
stack --resolver lts-X.Y [build|test|exec|...]
A more persistent solution is to have different .yaml configurations in your repository, that you can select using --stack-yaml
stack build # default is stack.yaml
stack --stack-yaml my-stack-lts-X.Y.yaml build
stack --stack-yaml my-stack-nightly-X-Y-Z.yaml build
I'm trying to test my Haskell package against several Stackage resolvers on Travis, but my --resolver environment variable is being ignored.
For example, if I specify
env:
- ARGS="--resolver lts-4.0"
in my .travis.yml, I still still seem to be using a different resolver (the one in my stack.yaml?) and GHC, as shown by lines like
Installing library in
/home/travis/build/orome/crypto-enigma-hs/.stack-work/install/x86_64-linux/lts-9.1/8.0.2/lib/x86_64-linux-ghc-8.0.2/crypto-enigma-0.0.2.9-6Cs7XSzJkwSDxsEMnLKb0X
in the corresponding build log, which indicates a different resolver (9.1), and corresponding GHC (8.0.2) being used.
How should my build (stack.yaml, .travis.yml, etc.) be configured to ensure that the resolvers (and corresponding GHC) I specify are used to preform my Travis builds and tests?
With env you just define environment variables. You still have to use them. stack on its own does not respect the ARGS variable, so use it in your script, e.g.
install:
# Build dependencies
- stack $ARGS --no-terminal --install-ghc test --only-dependencies
script:
# Build the package, its tests, and its docs and run the tests
- stack $ARGS --no-terminal --install-ghc test --haddock --no-haddock-deps
You should probably use a better name, for example RESOLVER:
env:
- RESOLVER=lts-4.0
- RESOLVER=lts-6.0
- RESOLVER=lts-8.0
install:
# Build dependencies
- stack --resolver $RESOLVER --no-terminal --install-ghc test --only-dependencies
script:
# Build the package, its tests, and its docs and run the tests
- stack --resolver $RESOLVER --no-terminal --install-ghc test --haddock --no-haddock-deps
Also keep in mind that it's usually a better idea to use multiple stack.yml to hold the configuration for that specific LTS variant.
For more information, see stack's Travis documentation and Travis' environment variables documentation.
I'm trying to set up Hakyll on a fresh Ubuntu 16.04 instance, but I can't seem to get the Stack-based setup instructions right.
Starting out with stack install hakyll, I get:
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for hakyll-4.9.3.0:
http-conduit-2.1.11 must match >=2.2 && <2.3 (latest applicable is 2.2.3)
Plan construction failed.
I got a similar error when tying to stack-install http-conduit-2.1.11, this time with:
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for http-conduit-2.2.3:
http-client-0.4.31.2 must match >=0.5 && <0.6 (latest applicable is 0.5.5)
http-client-tls-0.2.4.1 must match >=0.3 && <0.4 (latest applicable is 0.3.3.1)
Plan construction failed.
After resolving dependencies for this (also using Stack), I tried once again to stack install http-conduit-2.1.11, but I once again got the same dependency error.
The packages http-client-0.4.31.2 and http-client-tls-0.2.4.1 appear in my ~/.stack/precompiled/x86_64-linux/ghc-8.0.1/1.24.0.0/, which isn't explicitly in my $PATH, however that feels like an extremely hacky solution, and I haven't found any documentation recommending this approach.
How can I correctly install Hakyll on my machine?
Dependency management with stack is meant to be reproducible and declarative, that means that a stack project will only compile once all dependencies are recorded in the .cabal file(s) of the project and once the stack.yaml of the project defines versions for these dependencies either in the resolver or the extra-deps section.
Your confusion seems to stem from a misunderstanding of what stack install does. The command line help has this to say about it:
build Build the package(s) in this directory/configuration
install Shortcut for 'build --copy-bins'
...
--[no-]copy-bins Enable/disable copying binaries to the local-bin-path
(see 'stack path')
stack install does not save any dependencies.
So the proper way of making hakyll available as a dependency to your code is:
Create a proper stack project with stack init if you already have a Cabal package, or stack new if you don't.
Add hakyll to the library or executable build-depends in your .cabal file.
Attempt to stack build and follow the instructions in any error messages until all issues are resolved.
A simpler solution than #sjakobi's in this case was to specify a resolver as a command line option when starting a new Stack project:
stack install hakyll --resolver=5.11 --install-ghc
When building threepenny-gui on NixOS with stack --nix build, I got error saying I have the wrong version of ghc. Then I tried stack --nix setup, which doesn't run because bash is on an unexpected path on NixOS (that's expected, since the stack documentation only mentions stack --nix build not setup). What am I missing?
FYI, to deal with the zlib issues I have also added a shell.nix and default.nix per https://github.com/commercialhaskell/stack/issues/2130
EDIT: was able to build with the method suggested by mkkeankylej from the above link, i.e. editing ~/.stack/config.yaml and add zlib to buildInputs in shell.nix But I'd still like to know if there's a way to do it w/o falling back to nix-shell? It sounds like stack --nix build should work as long as the nix-shell method does.
First of all, threepenny-gui seems to provide no stack.yaml, i.e. the project isn't configured to be built with stack. Thus, I wonder why you even bother using stack since that is not going to be any easier than building the project with cabal-install or even Nix directly. The easiest and fastest way is probably to configure the build by running:
$ nix-shell "<nixpkgs>" -A haskellPackages.threepenny-gui.env --run "cabal configure"
Afterwards, you can simply "cabal build" the project and work with it (inside or outside of a nix-shell) as you please; the compiler and all necessary build dependencies are provided by Nix.
If you don't want that, then you can use the normal cabal-install approach:
$ cabal sandbox init
$ cabal install --only-dependencies
$ cabal configure
$ cabal build
That build is probably going to require system libraries, like libz, so you must make sure that those are available. There's a million different ways to accomplish that, but the cleanest IMHO is the following:
$ zlibinc=$(nix-build --no-out-link "<nixpkgs>" -A zlib.dev)
$ zliblib=$(nix-build --no-out-link "<nixpkgs>" -A zlib.out)
$ cabal install --only-dependencies --extra-include-dirs=$zlibinc --extra-lib-dirs=$zliblib
Last but not least, it's not obvious to me why your stack build --nix command won't succeed, because that command will use Nix to install the proper version of GHC automatically. So if that doesn't work, then my best guess is that you're using an old version of stack where that feature doesn't work properly. I've tried that build using the stack binary that Nix provides, stack 1.3.2, and it can compile a current git checkout of threepenny-gui just fine:
$ git clone git://github.com/HeinrichApfelmus/threepenny-gui.git
Cloning into 'threepenny-gui'...
remote: Counting objects: 4102, done.
remote: Total 4102 (delta 0), reused 0 (delta 0), pack-reused 4101
Receiving objects: 100% (4102/4102), 1.88 MiB | 581.00 KiB/s, done.
Resolving deltas: 100% (2290/2290), done.
$ cd threepenny-gui
$ stack init
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- threepenny-gui.cabal
Selecting the best among 9 snapshots...
* Partially matches lts-7.16
websockets-snap not found
- threepenny-gui requires >=0.8 && <0.11
Using package flags:
- threepenny-gui: buildexamples = False, network-uri = True, rebug = False
* Matches nightly-2017-01-17
Selected resolver: nightly-2017-01-17
Initialising configuration using resolver: nightly-2017-01-17
Total number of user packages considered: 1
Writing configuration to file: stack.yaml
All done.
$ stack build --nix --nix-packages zlib
threepenny-gui-0.7.1.0: configure (lib)
Configuring threepenny-gui-0.7.1.0...
threepenny-gui-0.7.1.0: build (lib)
Preprocessing library threepenny-gui-0.7.1.0...
[...]
Registering threepenny-gui-0.7.1.0...
This works without any specially edited config files for nix-shell, nor does it require special customization of stack.