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

Tue Mar 18 22:02:32 UTC 2014

I would imagine that the people working on Stackage may have already done
some work in this area.

https://github.com/fpco/stackage

-- Dan Burton

On Tue, Mar 18, 2014 at 2:54 PM, Tobias Dammers <tdammers at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140318/060ab470/attachment-0001.html>