Opened 7 years ago

Last modified 4 years ago

#1616 new proposed-project

Implement Cabal<->OS package management systems relations

Reported by: Augusto Owned by:
Priority: OK Keywords: cabal, pkg-config, usability
Cc: Difficulty: unknown
Mentor: not-accepted Topic: misc

Description (last modified by Augusto)

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[1], 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[2], 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 [2]. I'm editing to try to make things clearer.

Change History (7)

comment:1 Changed 7 years ago by Augusto

Summary: Cabal-system integration for requesting external dependenciesImplement Cabal<->OS package management systems relations

comment:2 Changed 7 years ago by Augusto

Description: modified (diff)

comment:3 Changed 6 years ago by dag

This should really be done using PackageKit?.

comment:4 in reply to:  3 Changed 6 years ago by Augusto

Replying to dag:

This should really be done using PackageKit?.

I haven't much experience with PackageKit? but it seems to only support a few linux distros out of the box. At least I couldn't find much information as to how to use it on OS X or Windows, for example.

There is no reason PackageKit? itself could not work as a plugin for step 2 above and I'd still avoid having to depend on anything but Haskell for the general case. However, it is an extra layer of abstraction between cabal (as seen as a build system) and package managers. Not sure if that's desireable.

I'll certainly take a look at how it implements all the back-ends, however.

comment:5 Changed 6 years ago by dag

Windows and OS X are difficult since they don't have package management at all, either way.

PackageKit? has the benefit of a single API which also includes methods for installing packages by criteria such as providing a header file, so you don't have to know about package names for all systems.

comment:6 Changed 6 years ago by Augusto

I wouldn't exclude those platforms for that reason, actually. On OS X you can have fink or mac ports, for example. And maybe on windows cygwin could be used. Not ideal and maybe not as feature complete, but at least it is something in improving user experience. I see no reason to exclude these commonly used platforms as long as there are developers available for them (such as myself).

Still, it is probably worth taking a look at it (at least for the API). As I said, no reason there should not be a back-end for PackageKit?, if there is someone to write and maintain code for it. And also, that it does not become mandatory, otherwise we might risk restricting functionality for users on OSes or distributions who are not targeted by that project.

comment:7 Changed 4 years ago by Edward Kmett

Priority: not yet ratedOK

This remains a fairly viable project proposal.

Note: See TracTickets for help on using tickets.