Changes between Initial Version and Version 2 of Ticket #1616


Ignore:
Timestamp:
Mar 24, 2012 1:18:53 PM (2 years ago)
Author:
passalaqua
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1616

    • Property Summary changed from Cabal-system integration for requesting external dependencies to Implement Cabal<->OS package management systems relations
  • Ticket #1616 – Description

    initial v2  
    1010 
    1111* 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: 
    12  * 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; 
    13  * 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; 
     12 * 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); 
     13 * 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; 
    1414* Extending cabal so that it can accept several environment aware plugins (and develop at least one): 
    15  * 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 request the install of external libraries to satisfy pkg-config dependencies (the user would still need to provide credentials to issue the apt commands, however due to the point above that would be at the beginning and we still get a hands-free install); 
     15 * 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); 
    1616 * 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.  
    1717* Extending cabal to provide dependencies information that can be converted for external packages registered in a system wide install: 
    18  * 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. This does not mean cross-compilation, however as I expect all of those to be run on the environment they support, but could be a nice first step in having cross-compilation farms for haskell projects that have their own cabal files. 
     18 * 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. 
     19 * 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. 
    1920 
    20 I might be mistaken on the size of this project and that is why I split it in those three separate steps. However 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. 
     21I 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. 
    2122 
    22 [1] - http://www.gentoo.org/proj/en/perl/g-cpan.xml 
     23I 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. 
     24 
     25 1. http://www.gentoo.org/proj/en/perl/g-cpan.xml 
     26 1. http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ 
     27 
     28 
     29Edit: Talked to Jürrien about this ticket and he mentioned the text on link [2]. I'm editing to try to make things clearer.