Ah -- so use cabal-dev for development and cabal-install when a version stabilizes? -- Conal<br><br><div class="gmail_quote">On Sun, Feb 5, 2012 at 4:20 PM, Jason Dagit <span dir="ltr"><<a href="mailto:dagitj@gmail.com">dagitj@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sun, Feb 5, 2012 at 10:48 AM, Conal Elliott <<a href="mailto:conal@conal.net">conal@conal.net</a>> wrote:<br>
> On Sun, Feb 5, 2012 at 12:43 AM, Andres Löh <<a href="mailto:andres.loeh@googlemail.com">andres.loeh@googlemail.com</a>><br>
> wrote:<br>
>><br>
>> Hi Conal.<br>
>><br>
>> > Thanks for the reply! Note that I get this message even running 'cabal<br>
>> > install' a second time after changing nothing. Is that scenario an<br>
>> > example<br>
>> > of what you mean by a "potentially dangerous cabal invocation"?<br>
>><br>
>> The check currently is entirely ad-hoc. Any reinstallation of an<br>
>> existing package triggers the warning. There's no hash comparison.<br>
><br>
><br>
> I'm confused. Isn't package re-installation an extremely common thing in<br>
> cabal while developing software?<br>
<br>
</div>I would say, "You should never mutate your user or global package<br>
database" and recommend using cabal-dev. The way cabal-install does<br>
destructive updates is evil. In particular, it likes to mutate your<br>
global or user package database. You run the risk of building<br>
something and then breaking it later by mutating its dependencies.<br>
<br>
With cabal-dev it would be more like this:<br>
# Suppose you're in the source of bar<br>
# Further suppose you just changed<br>
# dependency 'foo' that you're also developing<br>
cabal-dev add-source ../foo<br>
cabal-dev install --reinstall foo<br>
<br>
Technically this still mutates a package database but, it's a<br>
throwaway package database in the bar directory. I lose very little<br>
when I 'rm -rf cabal-dev dist' and my user and global package<br>
databases stay in tact. I feel as though I can't sing the<br>
sandboxed-build praise loudly enough. The time my computer takes to<br>
rebuild packages is negligible to the human time spent dealing with<br>
broken package databases..<br>
<br>
I hope that helps,<br>
Jason<br>
</blockquote></div><br>