libmpd: An MPD client library.

[ library, mit, network, sound ] [ Propose Tags ]

A client library for MPD, the Music Player Daemon (

[Skip to Readme]
Versions [faq] 0.1.2, 0.1.3, 0.2.0, 0.2.1, 0.3.0, 0.3.1, 0.4.0, 0.4.1, 0.4.2, 0.5.0, 0.6.0, 0.7.0, 0.7.1, 0.7.2, 0.8.0,,,,,, 0.9.0,,,,,,,,,
Change log NEWS
Dependencies base (==4.*), containers (==0.4.*), filepath (>=1.0 && <1.3), mtl (==2.0.*), network (>=2.1 && <2.4), old-locale (>=1.0 && <2.0), QuickCheck (==2.1.*), time (>=1.1 && <2.0), utf8-string (>=0.3.1 && <0.4) [details]
License LicenseRef-LGPL
Copyright Ben Sinclair 2005-2009, Joachim Fasting 2010, 2011
Author Ben Sinclair
Maintainer Joachim Fasting <>
Category Network, Sound
Home page
Bug tracker
Source repo head: git clone git://
Uploaded by JoachimFasting at Fri Apr 1 15:52:30 UTC 2011
Distributions Arch:, Debian:, Fedora:, FreeBSD:, LTSHaskell:, NixOS:, Stackage:
Executables test
Downloads 19124 total (354 in the last 30 days)
Rating (no votes yet) [estimated by rule of succession]
Your Rating
  • λ
  • λ
  • λ
Status Hackage Matrix CI
Docs uploaded by user
Build status unknown [no reports yet]





Build test driver


Build driver with hpc instrumentation


Use -f <flag> to enable a flag, or -f -<flag> to disable that flag. More info


Maintainer's Corner

For package maintainers and hackage trustees

Readme for libmpd-0.6.0

[back to package description]

libmpd-haskell: a client library for MPD


libmpd-haskell is a client library for MPD written in Haskell that aims to provide a safe and flexible yet consistent and intuitive interface to MPD's external API.


  • Latest release
  • git clone git://

There are packages available on the following systems:

Note that some of these packages are outdated.


The preferred method of building libmpd-haskell is using cabal-install, which takes care of dependency resolution and other minutiae.

To install libmpd-haskell, simply run:

cd libmpd-haskell && cabal install

Running tests

To run the libmpd testsuite, do:


Compiler support

We try to support the two last major versions of GHC, but only the latest version is actually tested for.

MPD API compliance

We try to comply with the latest version of the MPD protocol specification; any deviation from this is a bug.


With GHCi:

> import Network.MPD
> withMPD $ lsInfo ""
Right [Left "Tool", Left "Tom Waits",...]
> withMPD $ add "Tom Waits/Big Time"
Right ["Tom Waits/Big Time/01 - 16 Shells from a Thirty-Ough-Six.mp3",...]



  • master: Stable branch, should never break.
  • trunk: Development branch, turns into master
  • integrate: New, untested stuff

Develop against trunk unless the patch is fixing a problem known to exist in master.

Getting started

Create the clone thus:

git clone git:// trunk

To pull in new changes from upstream, use:

git pull origin trunk

To set up GIT hooks, see hooks/README in the source distribution.

General guidelines

  • When writing or modifying code, please try to conform to the surrounding style

  • All bugs that exist in master should be fixed there first, and then forward-ported to other branches.

  • If you introduce new functionality, please include a test case or at least document the expected behavior.

  • Use -Wall during development and try to eliminate all warnings before submitting your patch

  • Merge the upstream branch and redo your patch if necessary before submitting it

  • Merge with upstream on a regular basis for long-running branches

  • Before merging trunk with master, all tests must pass

  • When fixing a bug, try to implement a test for it first

  • Orphan instances are bad, use newtype if at all possible. Otherwise, please use {-# OPTIONS_GHC -fno-warn-orphans #-} in the affected source file and note why it is necessary to use it. This does not apply to the test harness

  • Branches are cheap, use them

Submitting patches

To submit a patch, use git format-patch and email the resulting file(s) to one of the developers or upload it to the bug tracker.

Alternatively you can create your own fork of the repository and send a pull request.

Submitting bug reports

See our bug tracker. Test cases are highly appreciated.

The release process

This outlines a general process used when cutting a new release:

  1. Decide what version component should be bumped
  2. Create a topic branch
  3. Run the test harness
  4. Fix errors
  5. Goto 3 unless there were no errors to fix
  6. Make sure is correct, add any contributors
  7. Update the NEWS
  8. Create a source distribution using cabal sdist
  9. Unpack the source to a temporary location and make sure it builds and that no files are missing
  10. Goto 8 unless there were no errors to fix
  11. Merge topic branch into master
  12. Tag the release by doing git tag -a -m vVERSION vVERSION

In general, patches that fix bugs are the most critical and should be released quickly (bumping the last version component). Remember, all deviations from the MPD protocol specification are considered bugs.

In some cases, say when the MPD protocol changes to the point of not being backwards compatible, a bump in at least the minor version is required.

The same goes for making backwards incompatible API changes (e.g., deletions, type changes).

The major version indicates "completeness", and after the first 1.0.0 release, all subsequent API changes must be backwards compatible (that is, only additions are allowed).

For users this means that restricting dependencies on libmpd-haskell to only allow changes in the last version component guarantees that your code will not break due to updates. All users are nonetheless encouraged to support the latest major/minor release at any given time, because there is no backporting.



LGPL version 2.1 (see LICENSE)

Contributors (in order of appearance)

Ben Sinclair <>

Joachim Fasting <>

gwern0 <>

Daniel Schoepe <>

Andrzej Rybczak <>