Ticket #1616 (new proposed-project)
Implement Cabal<->OS package management systems relations
|Reported by:||passalaqua||Owned by:|
|Priority:||not yet rated||Keywords:||cabal, pkg-config, usability|
Description (last modified by passalaqua) (diff)
Currently cabal manages the installation of hackage projects relatively well provided (among other things) that you have all the necessary external tools available and installed.
However, when certain tools are not available, such as alex or happy or some external library that cabal checks for with pkg-config, we lose the automated aspect of compiling and installing packages and confused and frustrated users. That is particularly bad for new users or people just wishing to use a certain haskell program available in hackage for which their OS does not have a pre-packaged version (such as an installer in windows or .deb in Debian/Ubuntu).
For instance, when issuing the command cabal install gtk in a fresh environment (say, ubuntu), it is going to complain about the lack of gtk2hs-buildtools. Then when issuing the command cabal install gtk2hs-buildtools it complains about the lack of alex. Installing alex is also not enough, as you also need happy. Cabal does not indicate that at first, though. Installing alex and happy still does not solve your problems as gtk depends on cairo, which checks for cairo-pdf through pkg-config and fails.
Point being that even though it is quite easy to install all those packages (and some you might not even have to be explicitly installed, as it can be provided by your haskell platform package), this automated process becomes manual, interactive and boring.
I propose extending cabal in three ways:
* Adding checks at the start of the compilation (of the first package) so as to solve all (or as many of) those dependencies at once:
- If it's an external executable, such as alex and happy, and we don't see it installed and on the path, complain or add it to the dependencies list to be installed (if we know how to, through point no.2 below);
- If it's something that is checked by pkg-config down the chain, it'd be nice to know in advance so we can first bother about all the libraries that it might need at once and stop babysitting the install so issue warnings before continuing;
* Extending cabal so that it can accept several environment aware plugins (and develop at least one):
- I like the thought of issuing apt-get install cabal-install && cabal update && cabal install cabal-ubuntu-integration or something like that and have cabal be aware that it is a big boy now and can suggest the install of external libraries to satisfy pkg-config dependencies (the user would still have to confirm and provide credentials, however due to the point above that would be at the beginning and we still get a nearly hands-free install);
- Obviously we are not limited to Ubuntu, used on this example; Other apt and rpm based systems and mac package management systems such as fink (though I have very limited experience on this side of things) could be supported similarly; Even windows could be, though that would probably require mode code to download/install cygwin/msys/painkillers to build some of the external libraries or provide reduced functionality.
* Extending cabal to provide dependencies information that can be converted for external packages registered in a system wide install:
- For this I took inspiration on the g-cpan tool for gentoo, which allows you to create on-the-fly ebuild files for PERL modules available at CPAN, which are then installed as regular packages on the system. I propose a generic way of doing this so that a simple haskell project can encapsulate the required conversion between .cabal and whatever recipe/ebuild/etc file your particular environment might need.
- Basically each package would be able to state: I depend on X, Y and Z libraries that are on hackage, E and F executables (which I might or might not know where they are) and on L, M and N libraries through pkg-config; mapping those names to packages from each package manager would still be a problem for the individual plugi-ns, though.
I think this would be a nice step in making Haskell even more accessible and slightly less frustrating for newcomers and for people trying interesting things in projects that depend on external libraries.
I do understand that cabal is not a package manager, however I see no reason why it should not be able to check for dependencies and issue warnings and suggestions in this way. And since those are warnings and not errors, the user can always ignore them and proceed.
Edit: Talked to Jürrien about this ticket and he mentioned the text on link . I'm editing to try to make things clearer.