Does anyone know if there exists an easy way to make Stack use specific patched version of Cabal library from my GitHub repository? I'm very pleased with how can I use forked versions of other packages by just putting them into packages: section of stack.yaml, but that doesn't seem to work with Cabal.
What I wanted is some way to specify git repository URL and revision in stack.yaml and have Cabal library built from that source, not from Hackage or whatever upstream repository. Could this be done?
Stack will use the newest version of the Cabal library in your global database, so installing it there (such as by using the Setup.hs script directly) should work.
Related
I'm trying to use a library that's on hackage, but not on stackage.
Currently, the code doesn't seem to be hosted on git anywhere (although I could "fork" it).
Are there any better ways than to just download the library locally and tell stack.yaml where to find it?
The library is parse-dimacs by the way.
stack allows you to specify dependencies that are not included in the (Stackage) snapshot as extra-deps in your stack.yaml.
To use parse-dimacs in your project, you'd add this stanza to your stack.yaml:
extra-deps:
- parse-dimacs-1.3
Is it possible to install package from sources with something similar to stack build package-name? (latter works with packages on Stackage, but not with custom ones)
Um, stack build (within the source directory)?
Stack doesn't really have a notion of installing libraries though, it only installs executables. To “install” locally-sourced packages, you need to specify what for you want them installed: add them as dependencies to another project, via a location: field in the packages: field in that project's stack.yaml file.
That's arguably sensible since, one might say, there's nothing you can do with an installed library except invoking it in another Haskell project (or in a REPL, which you can get with stack ghci). I personally don't hold with that though, I like actually being able to say install that library now. Which is one of the reasons I have always stuck to good old cabal-install rather than Stack. With that, you can just
cabal install
from within the source directory.
Cabal-install has often been criticised: its local installs can easily get out of sync and then you have weird dependency conflicts and need to rebuild lots of stuff. I never found this that much of a problem, and anyway this has been adressed in recent Cabal through Nix-style builds, which never produce conflicts.
I have a stack multi-package project where the "multi-package" is zip-conduit-0.2.2.2 (I needed to tweak some dependency versions to get it to compile with nightly-2015-10-12).
I use zip-conduit in the main package and I also want to in Setup.hs in order to be able to package up zip files.
I have build-type: Custom in my cabal file and stack build attempts to build Setup.hs. The problem is that building Setup.hs cannot find the dependency zip-conduit-0.2.2.2.
Can I use a multi-package dependency in Setup.hs? If so how? and if not, what is my alternative?
Note: I have seen this reference https://github.com/commercialhaskell/stack/pull/899, but I don't understand it.
It looks like you need to set the explicit-setup-deps setting to true for that package. It's unfortunate that Stack can't handle this situation automatically, but without dependency information in .cabal files, there seems to be no alternative.
See the linked issues from the documentation if you're interested in the history here.
I don't think it is possible to declare package dependencies for Setup.hs itself.
Some ideas:
Require that the dependent packages have already been installed.
Have Setup.hs shell out to an external command to perform the zipping, and just require that the external command has to exist.
Make the installer program an additional exe target in the cabal file. Before proceeding with the build of the library, Setup.hs can build the installer program target, then build the library, then use the built installer exe to install the library.
I'm attempting to start a new project using the Snap web framework. I used snap init to get my basic skeleton working. I also put http://www.stackage.org/lts/cabal.config next to my .cabal file. I didn't uncomment the line to use Stackage exclusively. So I tried to build and it failed and couldn't find the version of lens required by my .cabal file. The cabal.config file from Stackage specifies a version of lens that is not the same as the one in my .cabal file. So I deleted every constraint from my package list and did the usual cabal install --only-dep -j8 --enable-test and it worked!
However, I have always been told that package versions should be constrained. So when working with Stackage is it okay to leave package versions unconstrained? Should I downgrade my packages to the ones available in Stackage instead?
As far as I understand a cabal.config file specifies a set of dependencies with the specific versions that satisfy dependencies, so how does Stackage work? Is it just a subset of packages from Hackage that are proven to be compatible? Do they host their own packages or rely on Hackage for downloads?
Thanks in advance :)
Both options are available. The default option is what you did, and still goes to hackage to get the packages. You just added a filter to your cabal that prevents you from using any version of a package included in Stackage that was not tested to work together with all of the other packages.
The other option is to simply point your cabal repo to a Stackage url, and then you will download packages directly from the Stackage server. That server will only serve packages that are known to work together, so there is no need for additional constraints in your cabal file. I actually prefer this way of working.
In both cases, if you have additional constraints in your cabal file that are incompatible with the Stackage restrictions, your build will fail. If you use the first option, you will get dependency conflicts. When using the second option, the Stackage server will simply report that it does not have that specific package/version.
If a have a library checked out locally that builds with cabal that is used by an application. I would like to build my application against the the local library rather than something from hackage but I'm not sure how to do this. This seems like something I should be able to do, I'm just don't seem to be able to work out how.
Sandboxing
In case it matters or complicates things, the application is in a cabal sandbox with the cabal-sandbox-config file in the route directory of the application.
What I'm Trying to accomplish
I'm building Yesod application and I want to tweak the behaviour of one of the dependencies (shakespeare). I would like to build my application against my tweaked version.
Use cabal sandbox add-source, which is designed specifically for this use case.
Example:
$ git clone https://github.com/SomeUser/SomeDependency
$ cd /path/to/my-project
$ cabal sandbox add-source /path/to/SomeDependency
$ cabal build
As a bonus, if you later update SomeDependency and try to rebuild my-project, cabal will notice that and reinstall SomeDependency.
Option 1:
You can just clone the project, and then run a cabal install in the cloned directory.
git clone https://github.com/yesodweb/shakespeare.git
This will give you a directory shakespeare which will contain a .cabal file.
So just enter the directory and run a cabal install. This will install shakespeare. Now continue with installing your project.
The key point:
You need to install shakespeare yourself first so that when you compile your own project, ghc or cabal doesn't try to install the shakespeare dependency (from hackage by default) on its own.
Option 2:
Install hackage-server
Upload a copy of shakespeare (your tweaked version) to your local hackage
Edit your cabal config to prioritize your local hackage over the haskell-hackage
remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive
remote-repo: local.hackage:http://local.hackage/packages/archive
This might make sense if you're going to be tweaking several packages, but you're probably better off not doing this because among other things, keeping track of updates to your tweaked versions is going to be a nightmare.