[Haskell-cafe] uninstalling libraries

[Evan Laforge]

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 <danburton.email at gmail.com> 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" <qdunkan at gmail.com> wrote:
>
> On Mon, Nov 13, 2017 at 12:27 PM, Dan Burton <danburton.email at gmail.com>
> 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.
>
>