On Wed, May 04, 2022 at 06:42:53PM +0200, Francesco Ariis wrote:

Il 04 maggio 2022 alle 09:31 amindfv--- via Haskell-Cafe ha scritto:

...

I'm very comfortable using cabal's `v2-` nix-style local builds at home and at work, but on a personal machine at home I've clung to `v1-install` because I _really_ like the ability to choose which packages are available in a simple `ghci` session.

For a long time that's been impossible or painful with the `v2-` commands. What's the status these days? I'm particularly interested in how it works for packages that only exist locally without a Hackage server.

Does

cabal new-install --lib

do what you want?

I don't know; in the past it hasn't, and I wanted to see what the current recommendations are before going down a long and potentially incorrect path. Cheers, Tom

I concur with Tom's feeling and the fact that v2-install --lib has not always worked well for me. I kept around this error message from one of my sessions about 1/2y ago: Properties.hs:2:1: error: Ambiguous module name ‘Language.Copilot’: it was found in multiple packages: copilot-3.5 copilot-3.5 I spent hours and never figured out 1) what was going on or 2) how to select which copilot version I meant... :S The v1-style and, in particular, v1-sandbox, v1-install, and v1-exec, were great and, when combined, afforded the flexibility you were mentioning. The fact that they executed in a local environment, leaving everything else on the machine unaffected, and *with all packages in the sandbox enabled* in ghci/ghc by default, was intuitive and pleasant to work with. This made my job as a dev and maintainer so much easier. I've routinely worked with very large packages (some take 1h or more to compile). Being able to completely remove packages pertaining to one project (rm .cabal-sandbox) leaving everything else unaffected --just by virtue of the fact that that's where things were stored-- was an absolute game changer. Being able to run ghc/ghci on a package compiled with specific flags or changes, and knowing I was picking the right version just because of the location i was running ghci in, was incredibly simple to work with. It made installation of Haskell packages for newbies easier too: create a sandbox. mess around in it, and if you want to start over, just erase .cabal-sandbox. Done! All your other projects remain unaffected. There's no need to use advanced cabal commands or learn about how cabal chooses to store things in $HOME/.cabal. I know it may sound like a bit of a detour from your original request, but I think it isn't. If we had this back, we could have steps close to the old: cabal v1-sandbox init cabal v1-install cabal v1-exec -- ghci -hide-package which would give you the flexibility you were asking for. (sandboxes also had `v1-sandbox add-source` so you could let the sandbox know where to pick packages in your local drive from.) Cabal v2 has some --store argument to keep things local. It doesn't always work as expected (especially when installing tools), but I think it's because it has not been used as much. 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*. Experts, and those who want to optimize installation times, avoid re-compilation, those who know how to navigate $HOME/.cabal if need be, etc., can then choose to share that installation directory across projects and use $HOME/.cabal instead (or whatever else they want). But that's a conscious choice made by an expert who understands the choice. If we keep things local with --store, all we'd need is a way to run (v2-exec) ghc/ghci/whatever with all packages in the current environment available/enabled and you'd be very close to what you were asking for. Ivan On Wed, 4 May 2022 at 13:15, Richard Eisenberg wrote:

I have found that cabal v2-install --lib has not worked for me in this use case.

Instead, I use https://github.com/phadej/cabal-extras/tree/master/cabal-env, which despite being somewhat old at this point, works beautifully for the use-case Tom describes.

Richard

On May 4, 2022, at 12:56 PM, amindfv--- via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

On Wed, May 04, 2022 at 06:42:53PM +0200, Francesco Ariis wrote:

Il 04 maggio 2022 alle 09:31 amindfv--- via Haskell-Cafe ha scritto:

I'm very comfortable using cabal's `v2-` nix-style local builds at home and at work, but on a personal machine at home I've clung to `v1-install` because I _really_ like the ability to choose which packages are available in a simple `ghci` session.

For a long time that's been impossible or painful with the `v2-` commands. What's the status these days? I'm particularly interested in how it works for packages that only exist locally without a Hackage server.

Does

cabal new-install --lib

do what you want?

I don't know; in the past it hasn't, and I wanted to see what the current recommendations are before going down a long and potentially incorrect path.

Cheers, Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On Thu, 5 May 2022 at 06:30, Fendor 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

Cabal has a script capability, although it's poorly documented. For one-liners, there is `cabal repl --build-depends='...'. Not ideal, perhaps, but works well enough for me. On Thu, May 5, 2022 at 3:06 PM amindfv--- via Haskell-Cafe wrote:

On Thu, May 05, 2022 at 05:50:01AM -0400, 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*. Experts, and those who want to optimize installation times, avoid re-compilation, those who know how to navigate $HOME/.cabal if need be, etc., can then choose to share that installation directory across projects and use $HOME/.cabal instead (or whatever else they want). But that's a conscious choice made by an expert who understands the choice.

I'm actually coming from a bit of the opposite perspective. :)

I'm pretty happy, overall, with `cabal new-repl`, `cabal new-build`, etc. What I miss is the ability to have global installs. More specifically, I want to *pay all my costs at install time*. I'm okay with futzing with package dependencies, etc. (e.g. resolving conflicts in transitive dependencies) when installing a new package, but once I've paid that cost I want to be able to simply run `ghci` and have my curated set of packages available to me. I don't want to have to `mkdir foo ; cd foo ; cabal init ; $EDITOR cabal.project ; cabal new-repl` just to run a simple one-liner in ghci. I also like being able to write quick scripts and run them with `runghc` without creating an entire project for each and every one.

Cheers, Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh allbery.b@gmail.com

Hi Ivan, Here is some information about Cabal's script functionality: https://cabal.readthedocs.io/en/3.4/cabal-commands.html#cabal-v2-run Cheers, Travis On Mon, May 9, 2022 at 8:09 PM Ivan Perez wrote:

Hi,

I'd love to know more about that script capability, if you can spare the time to explain a bit.

It can be a separate thread or via private email if that may be noise in the conversation.

All the best,

Ivan

On Thu, 5 May 2022 at 15:11, Brandon Allbery wrote:

...

Cabal has a script capability, although it's poorly documented.

For one-liners, there is `cabal repl --build-depends='...'. Not ideal, perhaps, but works well enough for me.

On Thu, May 5, 2022 at 3:06 PM amindfv--- via Haskell-Cafe wrote:

...

On Thu, May 05, 2022 at 05:50:01AM -0400, 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*. Experts, and those who want to optimize installation times, avoid re-compilation, those who know how to navigate $HOME/.cabal if need be, etc., can then choose to share that installation directory across projects and use $HOME/.cabal instead (or whatever else they want). But that's a conscious choice made by an expert who understands the choice.

I'm actually coming from a bit of the opposite perspective. :)

I'm pretty happy, overall, with `cabal new-repl`, `cabal new-build`, etc. What I miss is the ability to have global installs. More specifically, I want to *pay all my costs at install time*. I'm okay with futzing with package dependencies, etc. (e.g. resolving conflicts in transitive dependencies) when installing a new package, but once I've paid that cost I want to be able to simply run `ghci` and have my curated set of packages available to me. I don't want to have to `mkdir foo ; cd foo ; cabal init ; $EDITOR cabal.project ; cabal new-repl` just to run a simple one-liner in ghci. I also like being able to write quick scripts and run them with `runghc` without creating an entire project for each and every one.

Cheers, Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh allbery.b@gmail.com

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.