[Haskell-cafe] cabal v2 global install status

[Ivan Perez]

On Thu, 5 May 2022 at 06:30, Fendor <power.walross at gmail.com> wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220509/3460c7b2/attachment.html>