On Thu, 5 May 2022 at 06:30, Fendor
Hi! Ivan Perez wrote: [...]
I don't know a single person from my personal life who managed to use the sandbox successfully.
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.
Quite contrary, personally, I used to be a flaming stack advocate because I was never able to use cabal for anything.
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. 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.
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.
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.
Ivan Perez wrote:
the fact that v2-install --lib has not always worked well for me.
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.
Ivan Perez wrote:
This workflow (installing packages in a store in the project directory) should be not just supported, but *encouraged*. Keeping all changes local *should be the default*.
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.
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?
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. Having a shared DB is great when things go well, but it ABSOLUTE sucks when they don't. Keeping the package DB local contains the damage when things go wrong. 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. But there's almost always a simple and easy fix for all problems cabal: rm -rf $HOME/.cabal (or rm -rf .cabal-sandbox). If your packages are local (sandboxed), the complexity of re-installing is linear to the packages in that project. If your cabal dir is shared, the complexity of re-installing is linear to the packages in ALL projects. We are lowering the best-case installation cost at the expense of increasing the worst-time installation cost (and losing more fine-grained control). 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. Ivan