<div dir="ltr">I would imagine that the people working on Stackage may have already done some work in this area.<div><br></div><div><a href="https://github.com/fpco/stackage">https://github.com/fpco/stackage</a><br></div></div>
<div class="gmail_extra"><br clear="all"><div>-- Dan Burton</div>
<br><br><div class="gmail_quote">On Tue, Mar 18, 2014 at 2:54 PM, Tobias Dammers <span dir="ltr"><<a href="mailto:tdammers@gmail.com" target="_blank">tdammers@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Wed, Mar 19, 2014 at 10:15:08AM +1300, Chris Wong wrote:<br>
> On Wed, Mar 19, 2014 at 9:47 AM, Tobias Dammers <<a href="mailto:tdammers@gmail.com">tdammers@gmail.com</a>> wrote:<br>
> > Hmm, but then, not all package managers/repositories use the same names<br>
> > for packages. So even if there were a way to extract the required<br>
> > libraries from cabal, feeding that information to the package manager<br>
> > isn't going to be trivial at all.<br>
><br>
</div>> It's not trivial, but I don't think it's difficult.<br>
><br>
> For example, Debian Haskell packages all take the form<br>
> libghc-NAME-dev. Fedora uses haskell-NAME. Sure, there's a bit of hard<br>
> coding involved, but the set of prominent distributions is finite.<br>
<br>
I think installing *haskell* packages is not the problem; cabal already<br>
does a decent job at that. The problem we're facing is that cabal can<br>
*only* install haskell packages, but not any of the native libraries<br>
they depend on (usually through FFI, but other examples exist, such as<br>
the pg_config tool from PostgreSQL).<br>
<br>
Besides naming convention issues (which could be compensated for with<br>
lookup dictionaries; a brute-force solution, sure, but better than<br>
nothing), a bigger problem is that sometimes packages don't match 1:1<br>
between distros, so one distro might just provide one monolithic<br>
foobar-dev package, while another might split it up into<br>
foobar-client-dev and foobar-server-dev, while yet another might provide<br>
more than one alternative.<br>
<br>
TL;DR: I think if we could just get a list of required native packages,<br>
we'd be a long way.<br>
<br>
><br>
> One problem, though, would be versions. I know we often ask for the<br>
> latest and greatest packages, which may conflict with what the<br>
> distribution supplies. So the benefits may not be as high as they<br>
> seem.<br>
><br>
> By the way -- has anyone looked into 0install? It hashes things,<br>
> similarly to Nix, but also tries to integrate with the existing<br>
> package manager. For example, if the user wishes to install GHC 7.6,<br>
> but the Debian repositories already supply it, it will invoke apt-get<br>
> instead of installing on its own.<br>
<div class="HOEnZb"><div class="h5">><br>
> > (And frankly, looking at build systems<br>
> > for other languages, I've never seen anything that does this - even<br>
> > autotools doesn't really do a lot more than check whether a library is<br>
> > available).<br>
> ><br>
> > That said, even if we could just get a list of required libraries out of<br>
> > cabal, in a somewhat human and machine readable format, that would be a<br>
> > huge win in itself.<br>
> ><br>
> > On Tue, Mar 18, 2014 at 11:48:33AM -0700, David Thomas wrote:<br>
> >> One option that just occurred to me would be to allow passing a script to<br>
> >> cabal that could be passed the extra-libraries (if any), and could install<br>
> >> if it knew the relevant OS packages (or NIX packages), or abort with a<br>
> >> cleaner error message.<br>
> >><br>
> >> Actually, wrapping ghc might be sufficient (though not ideal).<br>
> >><br>
> >><br>
> >><br>
> >> On Tue, Mar 18, 2014 at 11:29 AM, Michal Antkiewicz <<br>
> >> <a href="mailto:mantkiew@gsd.uwaterloo.ca">mantkiew@gsd.uwaterloo.ca</a>> wrote:<br>
> >><br>
> >> > This is not an immediate solution but I can imagine listing NIX packages<br>
> >> > as dependencies inside a cabal file, then NIX would create a sandbox with<br>
> >> > these dependencies and cabal would build in that sandbox. The advantages<br>
> >> > are that you're not messing around with the underlying operating system's<br>
> >> > packages, NIX handles all dependencies transitively, and everything is<br>
> >> > specified declaratively. Sounds like a nice GSoC project :-) You could<br>
> >> > also do cross GHC version's builds as GHC itself can be sandboxed. Quite<br>
> >> > intriguing.<br>
> >> ><br>
> >> > Michal<br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > On Tue, Mar 18, 2014 at 2:16 PM, Michal Antkiewicz <<br>
> >> > <a href="mailto:mantkiew@gsd.uwaterloo.ca">mantkiew@gsd.uwaterloo.ca</a>> wrote:<br>
> >> ><br>
> >> >> Certainly NIX is an interesting approach. It already comes with a large<br>
> >> >> base of dependencies, a format for specifying them. NIX can be installed in<br>
> >> >> any Linux distro and serve as an environment for building packages. That<br>
> >> >> might provide a cross-distribution solution to the native dependency<br>
> >> >> problem.<br>
> >> >><br>
> >> >> See, a nice post by Oliver Charles<br>
> >> >><br>
> >> >> <a href="http://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html" target="_blank">http://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html</a><br>
> >> >><br>
> >> >> Michal<br>
> >> >><br>
> >> >><br>
> >> >><br>
> >> >> On Tue, Mar 18, 2014 at 1:59 PM, David Thomas <<a href="mailto:davidleothomas@gmail.com">davidleothomas@gmail.com</a>>wrote:<br>
> >> >><br>
> >> >>> Ok, well, if that's the case I'd like to see about remedying that.<br>
> >> >>> Anyone have any thoughts as to how to best go about this? I'm not clear on<br>
> >> >>> exactly what info lives where, especially across systems. Entirely manual<br>
> >> >>> population would be a (barely) acceptable fallback.<br>
> >> >>><br>
> >> >>><br>
> >> >>> On Tue, Mar 18, 2014 at 9:36 AM, Dan Burton <<a href="mailto:danburton.email@gmail.com">danburton.email@gmail.com</a>>wrote:<br>
> >> >>><br>
> >> >>>> I have wished for this on multiple occasions. I don't believe such a<br>
> >> >>>> thing exists as of yet.<br>
> >> >>>><br>
> >> >>>> -- Dan Burton<br>
> >> >>>><br>
> >> >>>><br>
> >> >>>> On Tue, Mar 18, 2014 at 9:26 AM, David Thomas <<a href="mailto:davidleothomas@gmail.com">davidleothomas@gmail.com</a><br>
> >> >>>> > wrote:<br>
> >> >>>><br>
> >> >>>>> Is there a way to extract this? I'm looking to make it easier for<br>
> >> >>>>> newcomers to my project to get things building across different linux<br>
> >> >>>>> distros.<br>
> >> >>>>><br>
> >> >>>>> _______________________________________________<br>
> >> >>>>> Haskell-Cafe mailing list<br>
> >> >>>>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> >> >>>>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
> >> >>>>><br>
> >> >>>>><br>
> >> >>>><br>
> >> >>><br>
> >> >>> _______________________________________________<br>
> >> >>> Haskell-Cafe mailing list<br>
> >> >>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> >> >>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
> >> >>><br>
> >> >>><br>
> >> >><br>
> >> >> <<a href="mailto:mantkiew@gsd.uwaterloo.ca">mantkiew@gsd.uwaterloo.ca</a>><br>
> >> >><br>
> >> ><br>
> >> ><br>
> >> ><br>
> ><br>
> >> _______________________________________________<br>
> >> Haskell-Cafe mailing list<br>
> >> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> >> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
> ><br>
> > _______________________________________________<br>
> > Haskell-Cafe mailing list<br>
> > <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> > <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>