<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 5 May 2022 at 06:30, Fendor <<a href="mailto:power.walross@gmail.com">power.walross@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi!<br>
</p>
<div>Ivan Perez wrote:<br>[...]<br><br></div>I don't know a
single person from my personal life who managed to use the sandbox
successfully.<br></div></blockquote><div><br></div><div>Then nice to meet you! I have been using sandboxes successfully since before they were in cabal (there was a package that implemented this feature before). It's saved me countless hours of development time. I still use older versions of cabal specifically for this feature.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
Quite contrary, personally, I used to be a flaming stack advocate
because I was never able to use cabal for anything.<br></div></blockquote><div><br></div><div>I'm not going to go into details here so the thread is not derailed. We can take that offline. I will just say that I never found the features in stack a good approach from a development or maintainer point of view, and stack is banned from any project I have any say in. The only package I ever found difficult to install without stack was Hakyll (IIRC), and it was easier to just use something else.</div><div><br></div><div>I have yet to find something I can install with stack with a one liner that I cannot install with apt-get/cabal in an equally simple way.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
From my point of view, cabal's sandbox was a weird mess that was
hard to understand. Also, stateful mutations seem much more
complicated and error-prone to me.<br></div></blockquote><div><br></div><div>I imagine you may not care at this point, but I'd be happy to hear more via private message. For me, cabal sandboxes were pretty simple to use.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<br>
Ivan Perez wrote:<br>
> the fact that v2-install --lib has not always worked well for
me. <br>
<br>
I agree that `v2-install -lib` is a terrible interface, but
cabal-env shows how we can implement the desired functionality quite
beautifully, avoiding as much as stateful changes as possible.<br>
<br>
Ivan Perez wrote:<br>
> This workflow (installing packages in a store in the project
directory) should be not just supported, but <i>encouraged</i>.
Keeping all changes local <i>should be the default</i>. <br>
<br>
I don't think this should be the default, in my opinion optimising
the installation times, etc... is, especially for newcomers, what we
usually want.</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> You yourself said that you use this on very large
projects, so, isn't it more reasonable to make experts jump through
the extra hoop, e.g. by using cabal-env, to get the workflow you
want?<br></div></blockquote><div><br></div><div>I absolutely disagree. Users want, first and foremost, that it works **well**. There are too many instances in which 1) I package won't install without errors and 2) a package won't UPGRADE without errors. This is true for all languages. I've lost count of the amount of times I've found myself having to reinstall all JS or Ruby packages on my machine because I didn't know what was wrong and the original instructions no longer worked for an upgrade.<br></div><div><br></div><div>Having a shared DB is great when things go well, but it ABSOLUTE sucks when they don't.</div><div><br></div><div>Keeping the package DB local contains the damage when things go wrong.</div><div><br></div>A newcomer, and often-times an experienced user, won't know how to fix issues (with cabal commands or just by going into the directory). I don't know if it's still the case but, IIRC, up until not long ago, it was not possible to erase one particular package/project db from the new cabal's shared dir. That means it's an ever-growing directory and, once a user screws things up bad installing a project, they can't undo that mistake. There was no Ctrl+Z.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">But there's almost always a simple and easy fix for all problems cabal:<br></div><div class="gmail_quote">rm -rf $HOME/.cabal (or rm -rf .cabal-sandbox).<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">If your packages are local (sandboxed), the complexity of re-installing is linear to the packages in that project.</div><div class="gmail_quote"><br></div><div class="gmail_quote">If your cabal dir is shared, the complexity of re-installing is linear to the packages in ALL projects.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"></div><div class="gmail_quote">We are lowering the best-case installation cost at the expense of increasing the worst-time installation cost (and losing more fine-grained control).</div><div class="gmail_quote"><br></div><div class="gmail_quote">Packages will break. Cabal will break. Users don't know these tools well because they are complex and change often. Let's first get things right, then make them stable, then make them fast.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Ivan<br></div></div>