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 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.) On Sun, Nov 12, 2017 at 11:45 PM, Evan Laforge wrote:

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 uninstall information. (But even that potentially has problems, given that people are known to copy package registration information between package databases. If there is uninstall information in there, what happens if someone uninstalls via one or the other copy?)

Aren't packages only allowed to install a restricted set of things into a restricted set of places? We have the code (.hi, .a, .so, etc., in import-dirs / library-dirs), possibly library-specific data (I assume that's data-dir), and haddock (haddock-html and haddock-interfaces, awkwardly in separate places).

One problem is that I don't fully understand what those fields mean, is there documentation somewhere? And then the fact that these are all plural so presumably you could have a lot of them, what is that for?

I'm guessing library-dirs means something like "put this on your -L line" so it's clearly a mistake to interpret that as "here's where I put the library", and you'll have things like /usr/local/lib if you need to link external libraries.

Is there any more complicated install plan than put *.a, *.so, *.hi in $root/lib/$ghc/$package-$id, put haddock in $root/share/doc/$ghc/$package, put ad-hoc junk in $root/share/$ghc/$package? I assume there must be, but who's doing that and why? If it's OS packages, then they have their own uninstall mechanisms, presumably not ghc's problem.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

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 tooling should allow for upgrades or selective querying without having to manually uninstall. If it's just because you want the hard drive space back, then I don't really have anything for that.

I'm usually backing out of a version so I can install something else. I always keep just one version of each library installed. It's less clutter, and I never have any question about what package is linked to what version of what other package. Maybe it's not the official way to do things, but it's probably the reason I've never encountered cabal hell. Back in the day, of course, it was the only option. Nowadays we have cabal sandbox, but global packages are still simpler and more convenient. Maybe the new cabal install will improve on the situation, but it seems hard to beat the convenience, and doesn't provide the guarantee that there's no version skew anywhere. But, I'm not the only one with a single version policy, Google does too. Anyway, if there's no interest in robust uninstallation, I'll just continue using my script, with a few extra hacks to avoid deleting /usr/local/lib. Except that one hiccup it's actually worked fine for the last 15 years or so. For me, making a better API to the package db than ghc-pkg would probably do well enough.

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 ahead and make a sandbox for that. It hasn't really come up though. I'm certainly not trying to push this as The Solution, that's a bigger windmill than just uninstalls :) On Mon, Nov 13, 2017 at 4:56 PM, Dan Burton wrote:

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 two such projects simultaneously.

But if you, like Google, have enough control over all the projects worked on in order to dictate a single version policy, then that approach can certainly have its benefits. I'm not sure many people consider themselves in such a position, hence the pervasive assumption that sandboxing will be involved.

On Nov 13, 2017 14:45, "Evan Laforge" wrote:

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 tooling should allow for upgrades or selective querying without having to manually uninstall. If it's just because you want the hard drive space back, then I don't really have anything for that.

I'm usually backing out of a version so I can install something else. I always keep just one version of each library installed. It's less clutter, and I never have any question about what package is linked to what version of what other package.

Maybe it's not the official way to do things, but it's probably the reason I've never encountered cabal hell. Back in the day, of course, it was the only option. Nowadays we have cabal sandbox, but global packages are still simpler and more convenient. Maybe the new cabal install will improve on the situation, but it seems hard to beat the convenience, and doesn't provide the guarantee that there's no version skew anywhere. But, I'm not the only one with a single version policy, Google does too.

Anyway, if there's no interest in robust uninstallation, I'll just continue using my script, with a few extra hacks to avoid deleting /usr/local/lib. Except that one hiccup it's actually worked fine for the last 15 years or so. For me, making a better API to the package db than ghc-pkg would probably do well enough.

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. 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. 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. Cheers -Tyson 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. On Sun, Nov 12, 2017, 23:52 Brandon Allbery, wrote:

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

On Sun, Nov 12, 2017 at 11:45 PM, Evan Laforge wrote:

...

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 uninstall information. (But even that potentially has problems, given that people are known to copy package registration information between package databases. If there is uninstall information in there, what happens if someone uninstalls via one or the other copy?)

Aren't packages only allowed to install a restricted set of things into a restricted set of places? We have the code (.hi, .a, .so, etc., in import-dirs / library-dirs), possibly library-specific data (I assume that's data-dir), and haddock (haddock-html and haddock-interfaces, awkwardly in separate places).

One problem is that I don't fully understand what those fields mean, is there documentation somewhere? And then the fact that these are all plural so presumably you could have a lot of them, what is that for?

I'm guessing library-dirs means something like "put this on your -L line" so it's clearly a mistake to interpret that as "here's where I put the library", and you'll have things like /usr/local/lib if you need to link external libraries.

Is there any more complicated install plan than put *.a, *.so, *.hi in $root/lib/$ghc/$package-$id, put haddock in $root/share/doc/$ghc/$package, put ad-hoc junk in $root/share/$ghc/$package? I assume there must be, but who's doing that and why? If it's OS packages, then they have their own uninstall mechanisms, presumably not ghc's problem.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

On 2017-11-13 08:30 AM, Michael Orlitzky wrote:

The thing you want is called a package manager.

Evan, have you considered using Nix? It's a package manager that sits on top of the OS, and works on Linux and Mac OS. My Haskell development has been much happier since I switched to using Nix. Pros of Nix versus using cabal sandboxes: 1. Nix shares built libraries between projects, so doesn't chew up gobs of disk space for each project 2. You don't have to build huge numbers of libraries from source for each project, due to sharing. In fact, due to Nix's binary caching, you rarely have to build libraries from source at all. Cons: 1. If you want to use a newer version of a Hackage library than the one in in Nix, it's more work (although the packages track Hackage fairly closely). 2. Occasionally the version in Nix is broken.