Is there any command-line switch to stack that tells it to download all relevant packages without compiling/installing anything?
I think you probably want a combination of the --prefetch and --dry-run flags. For example, the following command:
stack build --prefetch --dry-run acme-missiles
downloads the acme-missiles-0.3.tar.gz source file without building it. If you later run stack build acme-missiles, it should configure and build it from the previously downloaded source.
If you want to download sources of the package locally you can use stack unpack command:
stack unpack typerep-map-0.3.0
The same can be done with cabal-install as well but with cabal get command:
cabal get typerep-map-0.3.0
Related
In order to be able to cancel a process on Windows, I need to make use of this fix for process package, which is still not released. I've tried adding the latest version from github as a dependency in my stack.yaml file:
packages:
- '.'
- location:
git: https://github.com/haskell/process.git
commit: 2fb7e739771f4a899a12b45f8b392e4874616b89
extra-dep: true
But the stack build command fails:
Process exited with code: ExitFailure 1
Logs have been written to: C:\Users\nadalesagutde\Documents\github\capitanbatata\sandbox\racing-turtles\.stack-work\logs\process-1.6.1.0.log
Configuring process-1.6.1.0...
Warning: The 'build-type' is 'Configure' but there is no 'configure' script.
You probably need to run 'autoreconf -i' to generate it.
setup.exe: configure script not found.
In the README of process is stated that autoreconf -i must be run before, but I don't know how to tell this to stack. Do I need some extra configuration in my stack.yaml file?
Looks like the package's git repo does not include the "configure" script, which is needed to use the package directly. The reason things work when downloading from hackage is that the source distribution does include the configure script. Frustrating! I think this is an atypical design decision for a package that uses configure. I've opened this stack issue: https://github.com/commercialhaskell/stack/issues/3534
Suggested workaround is to clone the repo as a submodule and run autoreconf -i manually.
Over time I've developed a messy system level Haskell installation that I'm not sure how to completely clean up. But for the most part this isn't of much concern as I simply use stack to manage per-project Haskell configurations. However as my project requirements diverge from my system Haskell setup, I wonder what the best way is to build and upload packages for Hackage.
Specifically (1) should I be using
stack exec -- cabal sdist
stack exec -- cabal upload
instead of simply
cabal sdist
cabal upload
and (2) should is there any reason to install a project version of cabal (with stack build cabal?)
Or is there some better stack-based approach to building and distributing to Hackage that doesn't involve invoking cabal directly?
Adding an answer based on my earlier comment.
stack offers equivalent functionality via its
stack sdist
stack upload
commands, which don't require interfacing with cabal directly in stack-based projects.
A full list of commands supported by stack can be obtained via:
$ stack --help
and the official documentation.
Individual commands also support --help to see what command line flags they support.
I want to build an environment for tutorial programs for Haskell, as I want to try and learn the language. So I read about Cabal and already have it on my machine, because I updated pandoc sometimes. I followed some tutorials, which state that you should run:
$ cabal sandbox init
$ cabal install --only-dependencies
$ cabal build
To have the environment set up. However, if I try so, I receive the following message:
$ cabal sandbox init
Writing a default package environment file to
/home/xiaolong/development/Haskell/cabal.sandbox.config
Using an existing sandbox located at
/home/xiaolong/development/Haskell/.cabal-sandbox
(Output of ls command)
$ ls
cabal.sandbox.config
And then:
$ cabal install --only-dependencies
cabal: Error reading local package.
Couldn't find .cabal file in: .
Huh? Suddenly there needs to be a .cabal file? This is puzzling to me. What steps do I need to take to get an environment, in which I can simply install packages and then use that environment to run code of any tutorials I choose?
This is another tutorial suggesting the described workflow. Something is there I am missing.
(I am under the impression, that cabal sandboxes are comparable to python virtualenvs, being useful in the way, that one doesn't need to install packages system-wide, but can instead install them in a directory and then use that environment to run programs.)
You need to have a cabal file inside it which describes your project's name, package dependencies, license etc. A cabal file can be generated using cabal init which is followed by a series of question you have to answer.
Once the initial cabal configuration file is created, you can go inside the package directory and create sandbox inside it using the commands you have described above.
You may be also interested in Stack which is another alternate (better, if you would ask me :)) tool for developing Haskell projects.
I have installed a bunch of packages to the snapshot database. I would now like a local copy of their documentation (even better if it's with hyperlinked source). Is there a way I can tell stack to run haddock on all of them?
EDIT (copied from my answer):
It seems that the obvious stack haddock package will install haddock for the package, so
$ cd ~/.stack/snapshots/x86_64-linux/lts-3.0/7.10.2/doc
$ stack haddock *
seems to do what I want, with two downsides:
I'll still need to remember to pass the --haddock flag to every build (there isn't a ~/.stack/config file, is there?)
It seems to rebuild them; is there a way to avoid that?
It seems that the obvious stack haddock package will install haddock for the package, so
$ cd ~/.stack/snapshots/x86_64-linux/lts-3.0/7.10.2/doc
$ stack haddock *
seems to do what I want, with two downsides:
I'll still need to remember to pass the --haddock flag to every build (there isn't a ~/.stack/config file, is there?)
It seems to rebuild them; is there a way to avoid that?
Step 1. Download and build the newest haddock. The build instructions are
in README.md.
git clone https://github.com/haskell/haddock.git
cd haddock
cabal sandbox init
cabal sandbox add-source haddock-library
cabal sandbox add-source haddock-api
cabal install --dependencies-only
cabal build
Then install the new haddock as haddock.real
cp dist/build/haddock/haddock /some/bin/dir/haddock.real
Step 2. Create a wrapper script named haddock:
#!/bin/sh
/some/bin/dir/haddock.real --hyperlinked-source "$#"
Don't forget to make it executable and put it in your path.
Step 3. Download and build standalone-haddock:
mkdir build-standalone-haddock
git clone https://github.com/feuerbach/standalone-haddock.git
cd standalone-haddock
cabal build
cp dist/build/standalone-haddock/standalone-haddock /some/bin/dir/
An example of how to use standalone-haddock:
mkdir temp
cd temp
cabal get heredoc-0.2.0.0
standalone-haddock -o doc heredoc-0.2.0.0
Then open doc/heredoc/index.html in your browser.
When you navigate to a type definition you should see a Source link on the right and that will bring you to the new hyperlinked source.
Suppose that I ran cabal sandbox init .. cabal install -j some-package and got a build failure in one of dependencies of some-package. One way to solve this is I notify the author of the failure and then wait for them to release a new version, but the process can sometimes be too slow. When the reason of the failure is obvious (which is often the case,) I want to launch my text editor and fix it by myself.
However when I ran find(1) for the filename from the error log in .cabal-sandbox cache directory, I could find no .hs files. Does the cabal command remove the entire source directory when GHC successfully or unsuccessfully finishes its execution? How can I intrude into cabal's task executions? Or, are there any standardized way to achieve my original goal of fixing software packages from Hackage by myself?
You can download package source with cabal get <package> then fix it and install into sandbox with cabal install <package-dir>.
E.g.
$ cabal get split
Unpacking to split-0.2.2/
$ vim split-0.2.2/split.cabal
$ cabal install ./split-0.2.2