[Haskell-cafe] uninstalling libraries
qdunkan at gmail.com
Tue Nov 14 01:39:01 UTC 2017
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
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
> 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>
>> 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.
>> 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.
More information about the Haskell-Cafe