"Is cabal-install stable enough yet that GHC should be inflicting it on newbies?"

#41

Thank you both for specifying stack. (And that’s why my questions have been careful to specify cabal-install.) So the collective wisdom is newbies should be using stack?

I think we’re suggesting sandboxes are something suitable for newbies; not once you become a ‘production programmer’. I’m not expecting on this thread we’ll hear from any actual newbies, so feedback from those in teaching is our best proxy.

#42

I think there are very different kinds of newbies, who cannot be served by the same means. If the goal is just to play with lambda calculus then, as you mentioned, there is little need for Cabal or Stack.

If the goal is to demonstrate how to solve real-world problems in a pure lazy language, Stack could be a better choice because of its swiss army knife approach, templates and hpack. Stack is very good at hiding implementation details: you don’t even need to know who GHC is (because Stack downloads and manages it transparently) or have any idea about Cabal files (indeed, YAML is enough).

However, if the goal is to eventually become proficient in Haskell product development then IMO starting with Cabal could be a better choice, precisely because it hides less details and forces you to learn basics of Haskell package ecosystem.

2 Likes
#43

I’ve used sandboxes for a long time and so do other languages.

But let’s see what’s wrong with v2 first:

  • cabal install --lib is a re-introduction of cabal hell
  • it does not support ad-hoc development easily, unless you
    • learn about store-dir
    • learn about ghc environment files
    • learn why cabal and ghc don’t “see” the same package lists
    • learn about nix-store/CAS
    • learn all the hidden v2 switches and understand how to combine them

It is so bad UX that, well, compiler/language developers have to ask how to use it.

It doesn’t support Makefile workflows or similar ones (such as copilot) properly.

I’m not suggesting v2 is useless. No. But we need to recognize that the current UX is insufficient.

2 Likes
#44

You seem to assume there is a single “collective wisdom” and a single “production programmer”. It is hardly so. There are different users, working in different environments, for different reasons and with different goals. They will value different functionalities and some tools will fit their workflow better than others.

What does “newbies” even mean? A senior software engineer who has been mostly writing Go or C# and want to try writing Haskell, is that a newbies? A doctorate student in CS who has done some ocaml before, is that a newbie? What about an artist who is interested in using Haskell to add music or visuals to their project? These are not rhetorical question, I actually do not know what you idea of a “newbie” is.

Perhaps the misconception in backed in the title of the thread: you do not have to use cabal-install, it’s not inflicted on anyone. You do not even need to use sandboxes. If someone does not like any of those tools or workflows, that is fine.

Haskell has a diverse community of users, let’s make it our value.

3 Likes
#45


How about…“someone not expecting to deal with this garbage in 2024” :

…could cabal (the tool) actually be worse to use than git?

3 Likes
#46

Thank you again Andrea. I was trying to make as few assumptions as possible, certainly nothing about how "production programmer"s want to work; nor that "senior software engineer"s (who are merely new to Haskell, not to development tooling) would be put off by starting with configuring a repository/sandbox rather than diving in to the new language.

Is chiefly who I had in mind as ‘newbie’. (That is, the learners, not the instructors :wink: ) Although:

(Note this thread got spawned from one started by Simon.)

Perhaps SPJ should also count as ‘newbie’? Or let me turn that question round. When the front page for GHC says:

Who will find that a “breeze”? And should that page be be more careful in what expectations it’s setting? (As the above discussion goes on to note, most places you go from that front page try to persuade you to install the full toolset, not bare-bones GHC. Certainly nowhere repeats your “do not have to use cabal-install”.)

So when I can make some time, I’ll have a crack at setting up a newbie-style sandbox avoiding all of the above.

1 Like
#47

When I learned haskell two years ago, i initially only needed ghc, and installing it was indeed, “a breeze” (edit: with ghcup). I remember I preferred it than manually putting the binary in my PATH, plus, knowing that eventually i might need cabal/stack/hls, i also knew that with a few clicks they would be installed/removed with the ghcup TUI.

(this experience was as a newbie that only knew python at the time)

5 Likes
#48

… by this definition we are all “newbies”. I am regular on cabal’s issue tracker so I am well aware of its short-comings. If you have a concrete proposal about what should be changed your are welcome to open an issue or a pull-request. We can work through the details there.

1 Like
#49

An analysis of the current tooling from the perspective of university students, teachers and lead-developers of GHC would be welcome :relaxed:

2 Likes
#50

You’ve basically described exactly what I want. I currently crudely approximate it by doing cabal install --lib of whatever packages I want to add, and after a while when that inevitably leads to errors, deleting ~/.ghc/x86_64-linux-9.10.1/environments/default and then doing cabal update followed by cabal install --lib of everything I had before plus the new one I want.

#51

Could you elaborate on why you want that, specifically, as opposed to creating a .cabal file or adding cabal flags at the top of the source file (see cabal v2-repl)?

(I know there are a variety of good reasons, I’m just curious what yours are, particularly if they’re not reasons I already know about.)

#52

It’s because I want a set of “ambient” packages to use in GHCi at any time without having a source file. For example, imagine you want to check if you’re remembering Gauss’s formula correctly. I find it convenient to just be able to type ghci from anywhere and then do import Test.QuickCheck and quickCheck $ \n -> n >= 0 ==> sum [1..n] === n * (n + 1) `div` 2.

3 Likes
#53

Do v2 builds even look at the globally installed packages? I would expect them to be isolated.

In which case, your use-case would be the main one for cabal install --lib.

#54

Thanks! How does that differ from having a directory with a .cabal file which contains in build-depends all the packages that you have “installed”? Then you can cd to that directory and use cabal repl to get GHCi with access to any of your “ambient” packages. I appreciate that this approach is slightly more “heavyweight”, but is there something else to it?

1 Like
#55

Yes and even worse: Special treatment of pre-installed packages by the solver · Issue #9669 · haskell/cabal · GitHub

3 Likes
#56

Feels like a bug if v2 is billed as “Nix-style.”

v2 at least needs a --pure flag imo.

#57

One reason is it feels less snappy. When comparing time ghci < /dev/null and time cabal repl --allow-newer < /dev/null, the latter usually takes 2-3x as long (only a few seconds, but still).

2 Likes
#58

Thanks! So we have at least two reasons:

  • It’s heavyweight to maintain the “dummy” cabal package setup
  • Even if you’re willing to make that effort cabal repl takes additional time to run

Is there anything else?

#59

Just my two cents as a haskell newbie that codes in enterprise:

I believe that most of the problems cited here are caused by the fact that cabal asks for too much information upfront. Usually in other languages you could just have a file with a list of dependencies and that’s it. You’d only need to fill all that extra info (package name, description, licence, version, author, maintainer, homepage, category, etc) when you are publishing it, which happens a lot less than just exploring code. It also doesn’t help that cabal still doesn’t have a command to add dependencies, like:

cabal init
cabal add QuickCheck
cabal repl

and having cabal detect current ghc/base and solving QuickCheck’s version (but still locally).
or even:

cabal repl
(inside repl): :add QuickCheck
and having cabal create a temporary project with the added dependencies

Having said that I believe that globally installed packages are evil and should be purged with fire (be it cabal-v1 or v2).

4 Likes
#60

There is an external command to do exactly that: