Strange Cabal behaviour

Learn
#1

So, I was trying to get the Control.Concurrent.Async module, which is exposed from the async package:

cabal new-install async

This doesn’t work. Cabal says that the package is up-to-date, but a) it produces a warning, and b) I can’t import module Control.Concurrent.Async into my Haskell code afterwards…

Warning: You asked to install executables, but there are no executables in
target: async. Perhaps you want to use --lib to install libraries instead.

And adding --lib just produces errors.

On the other hand, I can try this and it just works, even though listed as obsolete:

cabal v1-install async

Why is this please?

#2

Yes, this is a common problem. Installing libraries globally is still a pain point with cabal. There are a few things you can do.

  • Perhaps the simplest way is to just create a cabal package and add dependencies in the .cabal file.
  • Another option is to manually edit the contents of .ghc/<arch>-<ghc-version>/environments/default and remove the conflicting packages or just remove that file entirely.
  • You can also use cabal install --lib --package-env . async, this will create a special .ghc-environment file in the current directory that provides the async package if you run ghc in that directory. Note that this can cause unexpected behavior if you move to a different directory or if you forget that that file exists.
  • Otherwise you could try the cabal-env tool from cabal-extras, then you should just be able to do cabal-env async, but that is a bit experimental.

Edit: cabal-lib -> cabal-env

1 Like
#3

I see lately lot of users with this same problem and are perplexed by the cabal v2 workflow, heavily oriented to projects. New users did not suffer from cabal dependency hell of v1-install and dont see the point of the workaround of using ghc evironment files.
I think we should prioritize the conversion from cabal install --lib to cabal env based in the work of cabal-env (@jaror i think you were referring to it with cabal-lib) in cabal extras.
Cabal issue: https://github.com/haskell/cabal/issues/6481

3 Likes
#4

Which ones? As Jaror said, if you want a clean slate, axe:

~/.ghc/ARCH-OS-X.Y.Z/environments/default
# change ARCH and OS.X.Y.Z appropriately

Then learning how to create cabal projects is definitely the way to go.

#5

The v2- commands don’t fit my workflow either. If you just want to work with a particular set of libraries, v1- commands work very well and hopefully won’t be taken away any time soon.

2 Likes
#6

Hello Alex,
in general what does v1- has that v2-install --lib does not provide (yet) to you?

I missed v1 too for some things at first (install exes; install useful, nonmessy libs) but in the last couple of years things got quite perfect for my workflow.

#7

The ability to install more than one library with a command like cabal install <name of library>, use them together and not have confusing messages pop up about hidden libraries.

If I try to learn about the ‘v2-’ commands I get a lot of out of date and strange information. Eventually I find myself at the official documentation and after clicking around decide what I’m probably supposed to be doing is a ‘nix-style local build’. I don’t know what a local build is, or what nix is or therefore what it means to be in that style. So I read on further and that it combines non-sandboxed and sandboxed cabal. So that’s two more things I don’t understand. This really feels quite impenetrable. So I just try to use commands like the v1- ones I already know. Somehow if I run cabal install tidal cabal identifies that I want to install a library, but doesn’t install the library as a library and asks me to re-run the command with a --lib option to do that. I comply but quickly get to the point where my ‘default package environment’ is broken (the same library installed more than once) and go back to using the ‘v1-’ versions that worked.

2 Likes
#8

That is an excellent reply!

Do you mind if I open a ticket on cabal pointing to this thread? There for sure are insights on where and how to make onboarding more pleasant!

#9

You’d be welcome to but I’m guilty of moaning about this before on github so that might be a duplicate ticket. I think cabal env described above will help.

1 Like
#10

@FrancisKing, you have told us the command with which you installed async but you have not told us the command with which you tried to use async. That is essential information without which we cannot help you!

My guess is that you tried to use ghci or ghc, rather than cabal. Am I right? If so then my answer is to not use the former and instead use the latter.

If you want to play around with async in the REPL, then issue

cabal v2-repl --build-depends async

If you want to use async in a package you are writing then create a .cabal file and add async as a dependency. (N.B. in neither case do you need to explicitly install async. It will be installed automatically.)

You might think

But I want to use ghc/ghci!

I suggest giving up on that idea. It’s just not practical with cabal 2 style. Use cabal.

For more information see my article How I use cabal. If you need any more help with this workflow then feel free to reply here or open an issue on Tilapia.

3 Likes
#11

Everyone, thank you for your replies.

@tomjaguarpaw: I hadn’t realised that the command I used to access async was important in the question, but you are correct in your assumption that I was using ghci / :load / :reload in Visual Studio Code. Reading your comments, it seems that cabal v2 is a bit like a Haskell version of Leiningen - that I can handle! I’ve tried a few things, and it is doing what I hoped for. Thanks.

@tomjaguarpaw Can I contribute to Haskell documentation? I now have over 200 pages of notes - almost enough for a book. :slight_smile:

#12

Hi, and thanks for your interest in the documentation!

If you want to be directly involved in documenting base, then I invite you to read https://gitlab.haskell.org/ghc/ghc/-/issues/17929.

Otherwise, if you want to contribute to the cabal website, it’s on GitHub. The cabal manual is located here.

#13

I would love to see your notes! Do you have them anywhere publicly viewable, such as a git repo?

You’re also welcome to come over to Tilapia and open an issue to introduce yourself and suggest/ask what to work on, and to join the #haskell-docs IRC channel on Freenode.

1 Like
#14

Tilapia looks like a super cool initiative, thanks for setting that up!

1 Like
#15

OK. My GitHub skills are limited, but I appear to have the notes on GitHub now.

FrancisKing3/Haskell-Notes

3 Likes
#16

This is fantastic! Thanks for sharing.

1 Like