Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Cabal-install as a library #1597

wdanilo opened this Issue · 8 comments

6 participants


Hello! I would love to use Distribution.Client.* tree as a library - it has got a lot of useful functions, we can use to create custom behaviours. Right now it is used only by the cabal executable, but I do no think it will take much time to separate it as a library and create a simple Main.hs using this library to produce cabal executable.

I've asked about it on Haskell's IRC and I'm not the only person who finds this idea to be usefull.


I've wanted this in the past. I can only assume the reason it has been exposed as a library is to avoid caring about changing the APIs. But they seem pretty stable.


I've actually enabled this previously, but @dcoutts reverted that patch. See 7597a17.


@23Skidoo: I've created a patch right now and wanted to create pull request ...
So I understand that when I want to use functions from cabal-install I've got to manually copy the code to my sources? I completely do not understand such decision.

I understand @dcoutts, what you are talking about (7597a17):
"At some point in the future we probably do want a library or two
but we should make that decision deliberately and think about the API
that we want to expose."

But exposing all the unctions is less evil than not exposing the library at all, at least in my opinion.


Btw - can I ask why allmost no datatypes are derriving Show in cabal-install? It makes very hard to learn whats going under the hood without the ability to print something to terminal. I've added lots of "deriving (Show) for my own purposes and its a lot easier now.


So I'm a bit concerned about having the same package be both a lib and an exe. I fear that will create problems with mixing ghc versions etc. At the moment with cabal-install having no installed footprint other than the exe itself, it's easy to mix ghc versions and cabal binary versions.

However, having much of the cabal-install functionality available as one or more libraries is certainly a good plan. I just think we ought to make them as separate libs, and in a deliberate way, not just declare the package to be both a lib and an exe.

We could do this at the same time as reorganising the Cabal lib. e.g.:

  • Cabal (Distribution.*) -> cabal-lib
  • Cabal (Distribution.Simple.*) -> cabal-build (or cabal-build-simple)
  • cabal-install -> cabal
  • cabal-install (various bits thereof, e.g. package solver etc, hackage-client api) -> (one or more other libs)

As an example, the hackage doc builder client could do with getting access to some of the cabal-install functionality. So I can certainly see the utility of it.


Two thoughts:

  1. Some of the D.Client modules extend equivalent D.Simple modules. For example, cabal configure takes more options than setup configure. We may want to move some things back into D.Simple. One thing that's difficult now, for example, is that cabal build sometimes runs into trouble reconfiguring a changed package because it doesn't have access to the complete command line that was sent to cabal configure.

  2. Cabal and cabal-install dump all their messages into stdout/stderr and die on certain errors. Libraries must not do this! We already have code in cabal-install to work around the fact that the Cabal library we're using might call die, but we don't want to actually exit. We need to handle errors (all kinds of messages, actually) like a library.


+1 for reorganising Cabal lib. Small and well-organised library is easier to grasp, so it would be really helpful for new programmer who wants to use Cabal as a lib.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.