Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. coming to grips with hackage ([email protected])
2. Re: coming to grips with hackage (Brandon Allbery)
3. Re: coming to grips with hackage (Heinrich Apfelmus)
----------------------------------------------------------------------
Message: 1
Date: Tue, 4 Feb 2014 22:29:56 -0500
From: [email protected]
To: [email protected]
Subject: [Haskell-beginners] coming to grips with hackage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi there --
I've groveled through the Hackage site, I've read a bunch of cabal
documentation, and I've read far more blog entries, mailing list posts, and
other things turned up by Google than I can count. Please forgive me if my
confusions have been addressed elsewhere; if they have, I would appreciate a
pointer.
I'm having trouble wrapping my head around how to work with Hackage in the
context of a Linux distribution that already has its own package management
situation. Between distribution-provided packages containing Haskell programs
and/or libraries, system-wide cabal installs, user-specific cabal installs,
and cabal sandboxes, I can't seem to work out how the hackage/cabal architects
intend people (ie, me) to juggle things.
Here's a potential scenario: I want to use pandoc, for which my distro
provides packages, so I install it along with its various and sundry
dependencies using the package manager. Then I want to use another program
for which my distro *doesn't* provide a package, so I use cabal-install to
install it along with its various and sundry dependencies in ~/.cabal. Then I
have a crazy idea I want to play around with in code. Initially, I've got all
the libraries I need already installed, but eventually I discover there's a
feature in foo-1.1.3.4 that my idea just can't live without. Unfortunately,
foo-1.0.5.12 is required by pandoc.
At this point, it would seem like cabalizing my little idea and letting it
play by itself in a cabal sandbox is the preferred method. This seems
reasonable, I say to myself, and proceed to recompile every single library
upon which my little idea (recursively) depends. But then pandoc gets
updated, as well as many of the libraries upon which it depends, which results
in a wholesale upgrade of most of the system-wide libraries and now the stuff
I've installed in my home directory has all manner of broken dependencies.
There's probably a cabal-install command I can run at this point to clean
things up (though presumably I'd have to run it for every source tree that
uses a library that has been upgraded) but that's beside the point.
My confusion is how this scales. Enough little ideas that depend on
non-trivial libraries and I'm going to have eleventy-billion extremely similar
copies of Data.Text littered about my home directory. Is this really the
intention? Did I miss something? Are there better ``best practices'' than
what I've described? Any guidance is most appreciated! Thank you.
pete
PS. Bonus question, which seems intimately related: if A depends on B and a
new version of B appears, why does A necessarily need to be recompiled? Isn't
one of the big wins of shared objects avoiding this very necessity?
Presumably this is a consequence of how the GHC runtime does its linking, but
I couldn't find helpful documentation on this count.
------------------------------
Message: 2
Date: Tue, 4 Feb 2014 23:48:52 -0500
From: Brandon Allbery <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] coming to grips with hackage
Message-ID:
<cakfcl4vm95ozsdfrnhfukwhdsccs05ddp0thtdqz-mlhl3i...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Tue, Feb 4, 2014 at 10:29 PM, <[email protected]> wrote:
> I'm having trouble wrapping my head around how to work with Hackage in the
> context of a Linux distribution that already has its own package management
> situation. Between distribution-provided packages containing Haskell
> programs
> and/or libraries, system-wide cabal installs, user-specific cabal installs,
> and cabal sandboxes, I can't seem to work out how the hackage/cabal
> architects
> intend people (ie, me) to juggle things.
>
This is not a Hackage-specific issue; you will run into it with any
language ecosystem, and every language ecosystem has its own mechanisms for
dealing with it (usually involving some form of sandboxing). Indeed, some
languages pretty much require those mechanisms: all too often, you need a
separate rvm sandbox for multiple Ruby applications....
The general rule is that if you're just looking to install a few things
available from OS packages and are not doing development, use the OS
packages; otherwise, install just enough to be able to use cabal to install
stuff. Although this also may vary: in many cases you will want to install
the Platform libraries from your OS because you should really only have one
version installed and it should generally be the "blessed" stable version.
But if you're [say] intending to work with bleeding edge Yesod, then you
probably want to only install ghc and cabal-install from the OS.
Anyway, this question is why Haskell has hsenv, cabal-dev, and cabal
sandboxes; Ruby has rvm, Python has virtualenv, and Perl has perlbrew, and
other languages have their own mechanisms to deal with the same problems.
And pkg-config is (de facto and for the moment) the solution C and C++ use,
attacking it from a different direction.
--
brandon s allbery kf8nh sine nomine associates
[email protected] [email protected]
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140204/f5d97dab/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 05 Feb 2014 10:37:57 +0100
From: Heinrich Apfelmus <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] coming to grips with hackage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Brandon Allbery wrote:
> On Tue, Feb 4, 2014 at 10:29 PM, <[email protected]> wrote:
>
>> I'm having trouble wrapping my head around how to work with Hackage in the
>> context of a Linux distribution that already has its own package management
>> situation. Between distribution-provided packages containing Haskell
>> programs
>> and/or libraries, system-wide cabal installs, user-specific cabal installs,
>> and cabal sandboxes, I can't seem to work out how the hackage/cabal
>> architects
>> intend people (ie, me) to juggle things.
>>
>
> This is not a Hackage-specific issue; you will run into it with any
> language ecosystem, and every language ecosystem has its own mechanisms for
> dealing with it (usually involving some form of sandboxing). Indeed, some
> languages pretty much require those mechanisms: all too often, you need a
> separate rvm sandbox for multiple Ruby applications....
Pretty much this. Perhaps Nix can offer a more pleasant solution:
http://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html
Best regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 68, Issue 3
****************************************
