Re: [arch-haskell] help upgrading packages

16 May 2014

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