[arch-haskell] help upgrading packages

[Bardur Arantsson]

On 2014-05-15 23:18, Magnus Therning wrote:
> 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?
> 

What I do for executable-only is pretty simple. I use stow to manage all
non-distro software that I install, so I have one directory
per package, like so:

      ~/stow/ghc-mod/lib/ghc-mod/src
      ~/stow/hums/lib/hums/src
      (etc.)

Each of these directories contains a full sandbox with a locally-run
"cabal install".

For each package I add a "bin" directory, so

     ~/stow/ghc-mod/bin

and put in the necessary relative symlinks:

     ~/stow/ghc-mod-4.0.2/bin
        cpphs -> ../lib/ghc-mod/.cabal-sandbox/bin/cpphs
        ghc-mod -> ../lib/ghc-mod/.cabal-sandbox/bin/ghc-mod
        ghc-modi -> ../lib/ghc-mod/.cabal-sandbox/bin/ghc-modi
        hlint -> ../lib/ghc-mod/.cabal-sandbox/bin/hlint
        HsColour -> ../lib/ghc-mod/.cabal-sandbox/bin/HsColour

And finally use stow to "merge" the package into my ~ directory, so that
all the bin/ symlinks end up in my ~/bin.

(I use stow because I'm pretty pendantic about keeping "packages"
separate from everything else in my $HOME, but you could also just have
a ~/src with a sandbox for every package and add symlinks directly from
your ~/bin into the sandboxes. It's just that since all my non-haskell
non-distro self-built software is managed by stow, I chose to also use
stow for this.)

>>> 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.

I think we might be talking past each other...

I'm afraid I don't understand what you mean by "more manual work". Using
sandboxes the way I've described above doesn't really work at all for
executable + library situations. (So I offered a different solution to
that problem, namely cabal-ifying your own package that depends on a
library and installing your own package in a sandbox.)

>> 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.
> 

If we want to get pendantic, it's probably best to say Cabal vs.
cabal-install (which is where the "cabal" executable comes from, for
those who don't know).

I use cabal-install for all development with a .cabal file for each of
my projects, I never use Cabal (the library) directly as I've never
encountered a need to. I've not encountered many packages which use
anything other than the standard boilerplate Setup.hs/Setup.lhs file.
(Some packages with *really* complex build requirements do so, e.g.
Gtk2hs, but I assumed that's not quite the level of complexity we're
talking here.)

Anyway, enough rambling on...

Regards,