After I upload my package into hackages, it didn't generate haddock as others packages.
Anything I missed?
What I did is:
cabal dist and a package generated under dist directory.
open hackage web upload interface and upload the package.
open the URL and turns out package uploaded successfully but no haddock.
(the package do have a few docs)
Thank you.
Docs take a little bit of time to generate. I believe they are ran at midnight GMT.
In addition to Thomas's answer, run cabal haddock in your package directory and look for any errors.
Haddock is incredibly finicky in my experience, especially wrt. code blocks. If you get a parse error, just start deleting comments until docs can be generated. I usually use some extensively-documented package as a reference.
It looks like the documentation is missing because your package didn't build correctly. I found this near the end of the build log:
src/Network/OAuth2/HTTP/HttpClient.hs:18:8:
Could not find module `Control.Monad.Trans.Resource'
It is a member of the hidden package `resourcet-0.3.2.1'.
Perhaps you need to add `resourcet' to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
To avoid these sorts of problems, make sure your package builds locally with Cabal before uploading. Building with GHC directly will often mask these sorts of problems, since it will happily use whatever packages you have installed, regardless of whether you've mentioned them in your .cabal file or not.
Related
Do I need to manually edit the *.cabal file's build-depends section to add package as a project dependency?
Or perhaps there is a more convenient way that is not as error prone as manually mangling with build files is.
Thinking about functionality that pretty much any package manager I used has, namely
apt install
npm i
nuget install
Install Package
and so on. Does such functionality exist in Cabal?
There is no better way at the moment. The answer #danidiaz gave is essentially correct -- cabal-edit will automatically update cabal files for you. The plan is to import similar functionality into cabal directly. This was remains blocked on an exactprinter that can parse and emit cabal files precisely -- and work on that exactprinter is now underway.
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.
The source tree for happy contains AttrGrammarParser.ly and Parser.ly and the source tree for alex contains Scan.x. Yet, as far as I can tell in order to compile happy, we need to transform the .ly files into .lhs files using... happy, and in order to compile alex we need to transform the .x files into .hs files using... alex.
So it seems like there must be some bootstrapping going on here in order to compile either tool.
The Setup.lhs files for each project contain some template expansion, but, as far as I can tell, don't do anything in particular to do the bootstrapping.
How and where is the bootstrapping done?
I see that you are looking at the source tree of the darcs repositories for these packages on darcs.haskell.org. If you look at the actual tarballs on Hackage, you'll see something a bit different:
https://hackage.haskell.org/package/alex-3.1.4/src/dist/build/alex/alex-tmp/
https://hackage.haskell.org/package/happy-1.19.5/src/dist/build/happy/happy-tmp/
So basically the build artifacts necessary are shipped with the Hackage tarball. Cabal then just uses the build artifacts during the build process, thus avoiding the need to bootstrap locally. Cabal also knows how to preserve such build artifacts when you run cabal sdist for your own packages which you want not to depend on happy or alex, but last I checked this doesn't interoperate well with sandboxes, fwiw.
By the way, alex and happy development has moved to github:
https://github.com/simonmar/alex/
https://github.com/simonmar/happy/
When I run cabal install c2hs, it seems to finish correctly, but doesn't register the package. The package seems as if it's not even installed: it doesn't show up in ghc-pkg list, and rerunning cabal install c2hs goes through the same install procedure, instead of saying "All the requested packages are already installed".
I'd much appreciate any help getting this up and running. I'm using the prebuilt GHC 7.4.1 binary.
cabal install output: http://pastebin.com/CRUii8mm
imports are defunct: http://pastebin.com/r0aypxRA
Thanks in advance!
I believe c2hs is an executable, not a library. The cabal install output that you provided shows that the execeutable is placed in your private .cabal/bin directory.
The C2HS module has been removed from newer versions of c2hs, since sometime prior to c2hs-0.15. If you check out the c2hs source tree, you could find it by going back through the revisions. Or some other libraries include it. There's more information in this trac ticket. C2hs is moving towards making the functions in C2HS.hs completely unnecessary, although they aren't quite there yet (floating-point formats in particular need to be manually marshalled).
I know a Haskell module name, but I can't figure out in what package it is defined. This is bad because I can't compile without a package exposing this module.
Specificaly it is Text.Regex that I can't locate, but I would like to know how to solve that problem in general.
http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html
ghc-pkg find-module Text.Regex
But that only works for (a) recent GHCs, and (b) packages installed on your system.
You can also grep through the package file (e.g. /usr/lib/ghc-6.8.2/package.conf) to see what's installed.
You can also use either the haskell API search engines hoogle or the hackage search engine hayoo.
Text.Regex is in the package regex-base, and a few others built on top of it.
If you're using Cabal and you have the package installed, you can just try to compile it with cabal build, and Cabal will inform you of which package you forgot to add to your dependencies:
Main.hs:1:8:
Could not find module `Text.Regex':
It is a member of the hidden package `regex-compat-0.93.1'.
Perhaps you need to add `regex-compat' to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
The best tools are:
hoogle; or
hayoo.
Both are search engines for Haskell modules and functions.
If you are using Debian and the Debian-provided packages, there is a global documentation index at /usr/share/doc/ghc-doc/html/libraries/index.html which lists the package in the last column.