<div dir="auto"><div>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.<div dir="auto"><br></div><div dir="auto">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.</div><br><div class="gmail_extra"><br><div class="gmail_quote">On Nov 13, 2017 14:45, "Evan Laforge" <<a href="mailto:qdunkan@gmail.com">qdunkan@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On Mon, Nov 13, 2017 at 12:27 PM, Dan Burton <<a href="mailto:danburton.email@gmail.com">danburton.email@gmail.com</a>> wrote:<br>
> I also lean towards the "you shouldn't be trying to uninstall" mentality.<br>
> But it's worth discussing.<br>
><br>
> What is the motive for uninstalling? Is it to upgrade to a new version? To<br>
> narrow hoogle search results?  For these, our sandbox tooling should allow<br>
> for upgrades or selective querying without having to manually uninstall. If<br>
> it's just because you want the hard drive space back, then I don't really<br>
> have anything for that.<br>
<br>
</div>I'm usually backing out of a version so I can install something else.<br>
I always keep just one version of each library installed.  It's less<br>
clutter, and I never have any question about what package is linked to<br>
what version of what other package.<br>
<br>
Maybe it's not the official way to do things, but it's probably the<br>
reason I've never encountered cabal hell.  Back in the day, of course,<br>
it was the only option.  Nowadays we have cabal sandbox, but global<br>
packages are still simpler and more convenient.  Maybe the new cabal<br>
install will improve on the situation, but it seems hard to beat the<br>
convenience, and doesn't provide the guarantee that there's no version<br>
skew anywhere.  But, I'm not the only one with a single version<br>
policy, Google does too.<br>
<br>
Anyway, if there's no interest in robust uninstallation, I'll just<br>
continue using my script, with a few extra hacks to avoid deleting<br>
/usr/local/lib.  Except that one hiccup it's actually worked fine for<br>
the last 15 years or so.  For me, making a better API to the package<br>
db than ghc-pkg would probably do well enough.<br>
</blockquote></div><br></div></div></div>