Convenience in the Haskell ecosystem

[rhendric]

@sullyj3

At the least, you could have it work for the simple case and print an error for more difficult cases. That would be a strict improvement.

It’s not necessarily a strict improvement if it’s a habit that newbies learn that they then have to unlearn later, or if it deters people from using Cabal to its best potential. I can anticipate the Medium posts: don’t do [moderately sophisticated thing with Cabal files] because it breaks cabal add.

I am all for bringing new people into the Haskell ecosystem, but we should do it by bringing them to the actual Haskell ecosystem, not by setting up a fenced-in newbie area of the ecosystem that they have to leave in order to join the rest of us.

[Ambrose]

@rhendric

I can anticipate the Medium posts: don’t do [moderately sophisticated thing with Cabal files] because it breaks cabal add.

I think the dream of cabal add is for greenfield projects with fresh cabal files. Although fundamentally, cabal add is just gonna be a CLI that reifies all the lenses into build-depends in a cabal file, right? It’s a command line DSL for editing a specific file.

I agree that all told, cabal add is not actual super useful. It isn’t hard to just…edit a text file. But (whether it’s real or dramatized) apparently that’s hard enough for people that they quit Haskell?

I say “apparently” not sarcastically but literally. Like it’s an actual surprise to me that that could be true

[hasufell]

There are only a small number of possible if conditions in Cabal files (compiler, compiler version, architecture, platform, flags… did I miss any?). It doesn’t sound hard allowing a cli interface to “navigate” that path down.

Auto-detection seems too hard. You could assume the state of plan.json, but that’s also just a guess.

[vanceism7]

The thing is, in most other languages, adding a dependency is trivial, and usually there’s a nice command to make it happen. With cabal, as a newcomer, it’s quite difficult initially to figure some of this stuff out.

The cabal user guide is huge, and it’s quite easy to miss the section on how to add dependencies (which btw, seems to only be simply demonstrated in the quick start guide, in a very brief fashion). This is aggravating for someone who has set out to work on creating software. We want to build programs that solve our problem domain, not flip through the manual of a build tool trying to figure out how to add a dependency when in most other languages, it’s tool add <package>.

When you have business people checking in with you daily to see what your progress is, you don’t want to report back to them “I got stuck trying to add a dependency for half the day”. When people hear that haskell is this amazingly productive language and then get stuck for half a day trying to figure out the build tool, they’re gonna quit and go back to blub where its easy to do it.

Cabal is a complex and powerful tool, but not everyone wants to know about it. cabal add streamlines the process so people can focus on their work. Adding dependencies in cabal is trivial once you know how to do it, but it isn’t before then.

(Sorry btw @Ambrose, I didn’t mean that rant specifically towards you, I just clicked the reply button too quickly lol)

[rhendric]

‘The documentation is too opaque; let’s enhance the tool’ is certainly an argument. :emoji_conveying_good_natured_humor_and_not_an_attack:

[vanceism7]

@rhendric

:emoji_conveying_good_natured_humor_and_not_an_attack

Yea haha, addressing the documentation is one way to remedy the situation, and definitely a reasonable one; but I think adding some convenience to the tooling is a good thing.

Convenience is never usually essential or even very impressive, but it’s so influential. I think software lives or dies by convenience.

[rhendric]

@vanceism7

The cabal user guide is huge, and it’s quite easy to miss the section on how to add dependencies (which btw, seems to only be simply demonstrated in the quick start guide, in a very brief fashion).

Snark aside, I think this is a very valid complaint and I’d love to see the Cabal docs reorganized to address it, regardless of whatever effort goes into designing and implementing an imperative interface on Cabal files.

[bradrn]

@rhendric

Snark aside, I think this is a very valid complaint and I’d love to see the Cabal docs reorganized to address it, regardless of whatever effort goes into designing and implementing an imperative interface on Cabal files.

I completely agree. Even as someone who knows what I’m doing, I find the Cabal docs quite hard to navigate. Perhaps I’ll have a think about how to reorganise them.

(Also, where is the best place to propose and discuss such documentation changes?)

[Lsmor]

@sullyj3

At the least, you could have it work for the simple case and print an error for more difficult cases.

what’s wrong with cabal add [pkg-name:][ctype:]component <dependencies>. For example

• cabal add my-executable optparse
• cabal add my-library containers
• cabal add all text

I think, It is a good cli interface. The only (not) problem is that newcommers should learn that cabal uses components to create a package, something that (based on stack overflow questions) is not very well known.

@Ambrose

I agree that all told, cabal add is not actual super useful. It isn’t hard to just…edit a text file. But (whether it’s real or dramatized) apparently that’s hard enough for people that they quit Haskell?

yes but when you get the classic Module.Name belongs to hidden package xyz, consider adding it to your dependencies you push people to edit a file with very specific ad-hoc format. If that faliure was run cabal add component xyz people will be faced with something very common, which is running something in the console. And that is a very good improvement

@rhendric

I think this is a very valid complaint and I’d love to see the Cabal docs reorganized to address it,

Notice there are current efforts in this direction.

[Bodigrim]

I might be missing something, but

hackage-cli add-bound DEPENDENCY VERSIONRANGE CABALFILE

works for years. This is a solved problem.

You don’t need any exact-printing infrastructure to add a dependency: it’s absolutely fine to have multiple build-depends sections in a single component.

[tonyday567]

@Bodigrim

hackage-cli add-bound DEPENDENCY VERSIONRANGE CABALFILE

Yes, but what’s missing in the ecosystem is something to tie this together.

Cabal via the compiler tells you to add a package, that it’s hidden, say. You have to then jump on to hackage to find out the latest version, try and remember PVP to make a range up. Or add it manually to the file, run gen-bounds, find a pencil, or copy and paste the result from the command line back into the file manually.

All of this information is already available to cabal to do the entire task, but there are all these human steps needed that feel like unnecessary points of manual labour and potential bug generators which feel like they could be easily automated.

[Bodigrim]

@tonyday567

Yes, but what’s missing in the ecosystem is something to tie this together.

Agreed, but my point is that there is no technical challenge to implement cabal add (or a standalone cabal-add executable), which would be the first step in the direction. This can be done today.

[bradrn]

@Bodigrim

I might be missing something, but

hackage-cli add-bound DEPENDENCY VERSIONRANGE CABALFILE

works for years. This is a solved problem.

I don’t know so much… of the six reported issues for hackage-cli, one is that add-bound results in a malformed cabal file. This is exactly the kind of issue I would expect from a more ‘hacky’ solution like this, which works in most cases but fails when something unexpected comes up.

[malteneuss]

@tomjaguarpaw

Sounds like a great project! Do you have a link to what you’re working on? Perhaps the Haskell Foundation or Haskell.org committee could provide a space to host these docs. (I’m on the board of both, and happy to help try to make this happen.)

I’m starting with the documentation for Cabal as described here but i intend to separate guides from references, and then to make these guides more beginner-friendly for some widely used packages, probably aeson, process, yesod, persistent. Until then the hosting issue may have been solved by @Kleidukos in Haddock.

[tomjaguarpaw]

Wonderful! Would you be willing to post occasional updates here on Discourse so we can follow along? You are undertaking a valuable project

[wiz]

Convenient as it is, cabal install delenda est.

Just remove it already, and put a long sob story about generations of newbies getting their feet blown off or went python/node after trying to use it.

Add install-exe or something like that that would deal with the safe-ish part of it. And go to the drawing board for sane and ergonomic package management design. Enough is enough.

[Liamzy]

cabal install isn’t the problem, the problem is --lib, which the error messages tell you to use.

Why is cabal install foo --lib frowned upon?

I know it ties up the global namespace by importing the library into GHC, but I typically use it to initialize a package database. For instance, I just set up a new 8.4.4 installation, I tried cabal install acme-dont, then tried to ghci and :set -package acme-dont. There is no package environment visible to ghci, so it returns an error message. So, I then cabal install acme-dont --lib, and thus set up a package environment. Everything else is then installed without --lib, only being made vis…

According to posters on this thread, even --lib is safe to use under modern v2 / nix-style builds, because cabal-install (the executable) creates a dummy package env per build.

However, as I keep on trying to emphasize there, --lib is a general disaster. The only valid use, imo, is to create a package environment file by cabal install base --lib, and then it’s still footgunny once the package environment file exists (because apparently you’ll end up with different versions of the same package with the same identifier; cabal itself doesn’t care, but ghci / ghc do).

---

What I’d suggest would be:

1. cabal install --lib is dead; it’s marked experimental and I’m unsure as to anyone wants to finish the experiment?
2. cabal pkgenv and cabal pkgenv globalclean comes in with an unsafe warning.

Long-term, I hear some people working cabal seem interested in managing the global package env, but I guess it’s more a question of speculation, since that requires labor and effort, and… ummm…

[hasufell]

Talk talk talk.

Cabal needs a full time dev. Funded by the Haskell Foundation. It has become a bottleneck for the tooling experience.

[f-a]

cabal is almost 20 years old. Any tool with such a history — and with a plethora of contributors, and main developers — will have some warts and a good amount of legacy baggage to support.

Things have moved a great deal in the past — remember when we used sandboxes? — and are moving now.

[Liamzy]

There’s code by one Sven Panne that dates back to 2002, I believe, so Cabal is old enough to drink in the United States… no, I think that’s GetOpt in cabal that’s a fork of GetOpt from GHC.Base.

That said, aren’t you still looking for additional maintainers? That’s a different way to interpret hasufell’s first line, that instead of pure talk and talking about what can be done to improve Cabal, people actually sign up to help keep the thing running.