[arch-haskell] help upgrading packages

[Magnus Therning]

On Thu, May 15, 2014 at 05:29:13PM +0200, Bardur Arantsson wrote:
> On 2014-05-15 11:35, Magnus Therning wrote:
>> On Wed, May 14, 2014 at 10:47 PM, Bardur Arantsson <spam at scientician.net> wrote:
>>> On 2014-05-12 15:47, Magnus Therning wrote:
>>> [--snip--]
>>>
>>> All I needed to install build-wrapper (which I think was the
>>> inital "problem" package in this thread) was to do
>>>
>>> $ mkdir somewhere/buildwrapper
>>> $ cd somewhere/buildwrapper
>>> $ cabal sandbox init
>>> $ cabal install buildwrapper
>>>
>>> Add "somewhere/buildwrapper" to $PATH. Bonus points for using
>>> "stow" or similar.
>>> The key point in the above recipe is to *NOT* have all kinds of
>>> libraries installed system-wide (aka. via pacman). It usually
>>> works better that way.
>> 
>> Surely you should then `cabal install` the tool so you don't end up
>> with a complete sandbox with every dependency of buildwrapper's in
>> it, no?
> 
> You *do* need to keep the sandbox around (or at least parts of it).
> That's where the last "cabal install" line installs to.

Well, wouldn't you want the binary installed somewhere else, so you
don't need to keep the sandbox around?  Or do you build all your
haskell tools (hlint, hoogle, buildwrapper, hasktags, ghc-mod, etc) in
the same sandbox?

>> For some packages you would have to keep the sandbox around and do
>> it your way though, e.g. `pandoc` since it contains both a library
>> and executables.
> 
> If you want to use a sandboxed thing as a library then you need to
> develop "inside" the sandbox, so e.g. you'd just create a little
> cabal file for your project which declares all the dependencies and
> use cabal to build your project.

That's indeed the case, but that's *not* the point I was trying to
make.  If a package only consists of executables you can use the
`install` target of the Cabal file to install them.  If a package
consists of both a library and executables it's more manual work.

>>> Disclaimer: I haven't actually used buildwrapper personally, but
>>> one assumes that it just acts as an executable and doesn't install
>>> things into its own environment or other weird things.
>> 
>> Personally I think `cabal` really shines when doing more serious
>> Haskell development than I do.  I never test my Haskell packages on
>> anything other than the GHC that's in [haskell-core], and neither
>> do I test them against any other versions of packages than what's
>> found in [haskell-core].  My Haskell development is completely in
>> my free time and for fun.  I think that if I ever am lucky enough
>> find myself using Haskell professionally I'd quickly see more use
>> in what `cabal` has to offer.
> 
> Cabal also works beautifully for "hobby" type development. Once
> you've created a cabal file you hardly ever need to touch it again.
> :)

But it's overkill.  Do keep in mind that Cabal and `cabal` are two
different things.  Of course I use Cabal in all my packages, but I
don't use `cabal` at all.  The main reason I see for using `cabal`
would be when I need to maintain compatibility with multiple versions
of GHC and or packages I depend on.

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: magnus at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus

What gets measured, gets done.
     -- Tom Peters
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/arch-haskell/attachments/20140515/4424989b/attachment.sig>