I used to fight with a combination of system and cabal installed packages
under debian testing.
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.
To be fair, it's not absolute. I have found cabal sandbox useful to
compile things thing tons of dependencies, like pandoc. And if I
wanted to contribute to something with out of date version
requirements (and the first step is not helping them upgrade, for
whatever reason), then surely I'd go ah
The point at which I find a "single version policy" difficult is when I'm
trying to contribute to disparate packages or projects, with differing
maintainers and version requirements. One person wants to use the latest,
while another hasn't upgraded yet. Sandboxing is the only sane way to work
on tw
On Mon, Nov 13, 2017 at 12:27 PM, Dan Burton wrote:
> I also lean towards the "you shouldn't be trying to uninstall" mentality.
> But it's worth discussing.
>
> What is the motive for uninstalling? Is it to upgrade to a new version? To
> narrow hoogle search results? For these, our sandbox toolin
I also lean towards the "you shouldn't be trying to uninstall" mentality.
But it's worth discussing.
What is the motive for uninstalling? Is it to upgrade to a new version? To
narrow hoogle search results? For these, our sandbox tooling should allow
for upgrades or selective querying without havi
cabal and stack, and in the case of stack, cabal new-build, and possibly
cabal sandboxes, you probably shouldn't be trying to uninstall.
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
On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery wrote:
> This is something of a nasty problem, considering that storing uninstall
> information separately is not particularly robust. Perhaps ghc-pkg should,
> if it doesn't already, support extension fields that e.g. cabal can use to
> store unins
The problem is that the package db contains only what ghc needs to be able
to use the library; not the additional information needed to safely remove
it. (There are other package systems with this problem, notably Apple's.
Apple decided that instead of solving it, they would only support
applicatio
For a very long time, I've used a local script to uninstall libraries.
Initially it was very simple: use ghc-pkg field to find and remove
library-dirs, import-dirs, and haddock-html, and call ghc-pkg
unregister.
It served well for a long time, but eventually I got tired of copy
paste games and ext
