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.em...@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" <qdun...@gmail.com> wrote: > > On Mon, Nov 13, 2017 at 12:27 PM, Dan Burton <danburton.em...@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. > > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users