[Haskell-cafe] Listing native package requirements based on cabal information

Tue Mar 18 23:30:25 UTC 2014

Well, if naming is the problem then you need a cross-distribution package repository. The only one like that across linuxes and MacOS that I know of is NIX packages. 

Building inside a NIX sandbox would shield Cabal from the OS packages as distros often come with older versions.

Nix will also install all the dependencies transitively, so a cabal package only has to list the direct deps.

Re: 0 install - haven't used it but might be an alternative if it is cross-distribution and for mac.

Michal

  Original Message  
From: Tobias Dammers
Sent: Tuesday, March 18, 2014 5:57 PM
To: Chris Wong
Cc: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Listing native package requirements based on cabal information

On Wed, Mar 19, 2014 at 10:15:08AM +1300, Chris Wong wrote:
> On Wed, Mar 19, 2014 at 9:47 AM, Tobias Dammers <tdammers at gmail.com> wrote:
> > Hmm, but then, not all package managers/repositories use the same names
> > for packages. So even if there were a way to extract the required
> > libraries from cabal, feeding that information to the package manager
> > isn't going to be trivial at all.
> 
> It's not trivial, but I don't think it's difficult.
> 
> For example, Debian Haskell packages all take the form
> libghc-NAME-dev. Fedora uses haskell-NAME. Sure, there's a bit of hard
> coding involved, but the set of prominent distributions is finite.

I think installing *haskell* packages is not the problem; cabal already
does a decent job at that. The problem we're facing is that cabal can
*only* install haskell packages, but not any of the native libraries
they depend on (usually through FFI, but other examples exist, such as
the pg_config tool from PostgreSQL).

Besides naming convention issues (which could be compensated for with
lookup dictionaries; a brute-force solution, sure, but better than
nothing), a bigger problem is that sometimes packages don't match 1:1
between distros, so one distro might just provide one monolithic
foobar-dev package, while another might split it up into
foobar-client-dev and foobar-server-dev, while yet another might provide
more than one alternative.

TL;DR: I think if we could just get a list of required native packages,
we'd be a long way.

> 
> One problem, though, would be versions. I know we often ask for the
> latest and greatest packages, which may conflict with what the
> distribution supplies. So the benefits may not be as high as they
> seem.
> 
> By the way -- has anyone looked into 0install? It hashes things,
> similarly to Nix, but also tries to integrate with the existing
> package manager. For example, if the user wishes to install GHC 7.6,
> but the Debian repositories already supply it, it will invoke apt-get
> instead of installing on its own.
> 
> > (And frankly, looking at build systems
> > for other languages, I've never seen anything that does this - even
> > autotools doesn't really do a lot more than check whether a library is
> > available).
> >
> > That said, even if we could just get a list of required libraries out of
> > cabal, in a somewhat human and machine readable format, that would be a
> > huge win in itself.
> >
> > On Tue, Mar 18, 2014 at 11:48:33AM -0700, David Thomas wrote:
> >> One option that just occurred to me would be to allow passing a script to
> >> cabal that could be passed the extra-libraries (if any), and could install
> >> if it knew the relevant OS packages (or NIX packages), or abort with a
> >> cleaner error message.
> >>
> >> Actually, wrapping ghc might be sufficient (though not ideal).
> >>
> >>
> >>
> >> On Tue, Mar 18, 2014 at 11:29 AM, Michal Antkiewicz <
> >> mantkiew at gsd.uwaterloo.ca> wrote:
> >>
> >> > This is not an immediate solution but I can imagine listing NIX packages
> >> > as dependencies inside a cabal file, then NIX would create a sandbox with
> >> > these dependencies and cabal would build in that sandbox. The advantages
> >> > are that you're not messing around with the underlying operating system's
> >> > packages, NIX handles all dependencies transitively, and everything is
> >> > specified declaratively. Sounds like a nice GSoC project :-) You could
> >> > also do cross GHC version's builds as GHC itself can be sandboxed. Quite
> >> > intriguing.
> >> >
> >> > Michal
> >> >
> >> >
> >> >
> >> > On Tue, Mar 18, 2014 at 2:16 PM, Michal Antkiewicz <
> >> > mantkiew at gsd.uwaterloo.ca> wrote:
> >> >
> >> >> Certainly NIX is an interesting approach. It already comes with a large
> >> >> base of dependencies, a format for specifying them. NIX can be installed in
> >> >> any Linux distro and serve as an environment for building packages. That
> >> >> might provide a cross-distribution solution to the native dependency
> >> >> problem.
> >> >>
> >> >> See, a nice post by Oliver Charles
> >> >>
> >> >> http://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html
> >> >>
> >> >> Michal
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Mar 18, 2014 at 1:59 PM, David Thomas <davidleothomas at gmail.com>wrote:
> >> >>
> >> >>> Ok, well, if that's the case I'd like to see about remedying that.
> >> >>> Anyone have any thoughts as to how to best go about this? I'm not clear on
> >> >>> exactly what info lives where, especially across systems. Entirely manual
> >> >>> population would be a (barely) acceptable fallback.
> >> >>>
> >> >>>
> >> >>> On Tue, Mar 18, 2014 at 9:36 AM, Dan Burton <danburton.email at gmail.com>wrote:
> >> >>>
> >> >>>> I have wished for this on multiple occasions. I don't believe such a
> >> >>>> thing exists as of yet.
> >> >>>>
> >> >>>> -- Dan Burton
> >> >>>>
> >> >>>>
> >> >>>> On Tue, Mar 18, 2014 at 9:26 AM, David Thomas <davidleothomas at gmail.com
> >> >>>> > wrote:
> >> >>>>
> >> >>>>> Is there a way to extract this? I'm looking to make it easier for
> >> >>>>> newcomers to my project to get things building across different linux
> >> >>>>> distros.
> >> >>>>>
> >> >>>>> _______________________________________________
> >> >>>>> Haskell-Cafe mailing list
> >> >>>>> Haskell-Cafe at haskell.org
> >> >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> Haskell-Cafe mailing list
> >> >>> Haskell-Cafe at haskell.org
> >> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >> >>>
> >> >>>
> >> >>
> >> >> <mantkiew at gsd.uwaterloo.ca>
> >> >>
> >> >
> >> >
> >> >
> >
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe