<p dir="ltr">I used to fight with a combination of system and cabal installed packages under debian testing.</p>
<p dir="ltr">Then, about a year ago, the frustration became too much and I switched to using nix, intero in emacs, and stack with the nix resolver, all installed with nix on my debian machine. Couldn't be happier.</p>
<p dir="ltr">If I want a new dependency, I just add it to my cabal file, rerun cabal2nix, restart intero and it all just works. Talk about a vastly improved experience over what I used to have.</p>
<p dir="ltr">As a major bonus I now also run the exact same setup on our HPC cluster, which runs centos 6, and I can switch between them seamlessly.</p>
<p dir="ltr">Cheers -Tyson</p>
<p dir="ltr">PS: The only gotcha I ran into so far is that stack/intero installs a ghcpaths package outside of nix on first startup that can causes conflicts with some packages. Turns out you can just manually remove it though to resolve this, so no big deal.</p>
<br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 12, 2017, 23:52 Brandon Allbery, <<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">cabal and stack, and in the case of stack, cabal new-build, and possibly cabal sandboxes, you probably shouldn't be trying to uninstall.<div><br></div><div>And yes, the data lines are telling ghc what to compile / link with, not files but command line inclusions. And this will be especially messy on OS X because of the need to group .dylibs together to avoid making the link commands section too large with multiple RPATH entries. (Which will also complicate uninstallation there.)</div></div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 12, 2017 at 11:45 PM, Evan Laforge <span dir="ltr"><<a href="mailto:qdunkan@gmail.com" target="_blank">qdunkan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery <<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>> wrote:<br>
> This is something of a nasty problem, considering that storing uninstall<br>
> information separately is not particularly robust. Perhaps ghc-pkg should,<br>
> if it doesn't already, support extension fields that e.g. cabal can use to<br>
> store uninstall information. (But even that potentially has problems, given<br>
> that people are known to copy package registration information between<br>
> package databases. If there is uninstall information in there, what happens<br>
> if someone uninstalls via one or the other copy?)<br>
<br>
</span>Aren't packages only allowed to install a restricted set of things<br>
into a restricted set of places? We have the code (.hi, .a, .so,<br>
etc., in import-dirs / library-dirs), possibly library-specific data<br>
(I assume that's data-dir), and haddock (haddock-html and<br>
haddock-interfaces, awkwardly in separate places).<br>
<br>
One problem is that I don't fully understand what those fields mean,<br>
is there documentation somewhere? And then the fact that these are<br>
all plural so presumably you could have a lot of them, what is that<br>
for?<br>
<br>
I'm guessing library-dirs means something like "put this on your -L<br>
line" so it's clearly a mistake to interpret that as "here's where I<br>
put the library", and you'll have things like /usr/local/lib if you<br>
need to link external libraries.<br>
<br>
Is there any more complicated install plan than put *.a, *.so, *.hi in<br>
$root/lib/$ghc/$package-$id, put haddock in<br>
$root/share/doc/$ghc/$package, put ad-hoc junk in<br>
$root/share/$ghc/$package? I assume there must be, but who's doing<br>
that and why? If it's OS packages, then they have their own uninstall<br>
mechanisms, presumably not ghc's problem.<br>
</blockquote></div><br><br clear="all"><div><br></div></div><div class="gmail_extra">-- <br><div class="m_-6576402674556291039gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</div>
_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org" target="_blank">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users</a><br>
</blockquote></div>