Shell scripts for support of Cabal maintenance

Latest on Hackage:0.1.1

This package is not currently in any snapshots. If you're interested in using it, we recommend adding it to Stackage Nightly. Doing so will make builds more reliable, and allow to host generated Haddocks.

BSD3 licensed by Henning Thielemann

This is a collection of Bash shell scripts for support of Cabal package development. The scripts are installed in your cabal/share directory, thus you may extend your command search path accordingly.

If you are in the directory of mypkg (the directory that contains mypkg.cabal), then you may run scripts in the following way:

  • cabal-test dist/mypkg-0.1.tar.gz: Unpack the tarball in the /tmp directory and try to build it using Cabal. This check helps to find missing files in the Cabal package description.

  • cabal-darcs-bump-version 0.2: Replaces the package and the repository version number in your Cabal file by 0.2 and records an according Darcs patch.

  • cabal-darcs-upload 0.2: This command supports the following workflow: Say, on Hackage there is version 0.0.1 of your package and the cabal file in the darcs repository says Version: 0.1. Now you decide to finish that version and to work next on the version 0.2. This is the time when you call cabal-darcs-upload 0.2. The call runs cabal-test and cabal check before uploading. Then it tags the repository with the current package version number. Then it uploads the package to Hackage. Finally it bumps the version of the package to 0.2. This workflow makes sure, that you never have two different contents for the same version in Hackage and in your darcs repository. If you set the environment variable HACKAGEUSER, then this will be automatically used for upload.

  • cabal-darcs-repository: Shows some lines of Source-Repository fields, that you may copy into mypkg.cabal. We fetch the repository URL from Darcs files. Unfortunately, as developer you will certainly use a private read-write access to your repository like, whereas the Cabal field may contain a public read-only access, such as

  • cabal-main-directory If started in a source sub-directory then it prints the closest super-directory containing a cabal file. This way a build script can automatically find the directory where to run cabal build.

  • cabal-find-revdeps author package: Find all Cabal files of packages of a certain author that import a certain package. This is intended for updating a bunch of packages, when a new version of a basic packages shall be supported. In this use case, author should be your name and package should be the basic package to adapt to. Actually the script is very silly and just scans for the author name and the package name and does not check, where in the Cabal file they occur. Thus be prepared for false positives search results. The script also filters out package paths that contain underscores in order to hide paths in _darcs directories and branched darcs repositories that usually have names like pkg_0. I advise to process the packages with for pkg in `cabal-find-revdeps author package` ; do (cd `dirname $pkg`; bash); done . This for loop will take you successively into every package directory. There you can perform some operations and you can browse the shell history for the commands you performed for the previous packages. If you are finished with a package, then you just call exit, and the for loop automatically puts you in the next package directory. See also package cabal-sort that provides the commands cabal-sort and ghc-pkg-dep.

Depends on:
Used by 1 package:
comments powered byDisqus