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.
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.)
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
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.
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
Yes and even worse: Special treatment of pre-installed packages by the solver · Issue #9669 · haskell/cabal · GitHub
3 Likes
Feels like a bug if v2 is billed as “Nix-style.”
v2 at least needs a --pure flag imo.
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
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 repltakes additional time to run
Is there anything else?
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
There is an external command to do exactly that:
Yes, but that’s yet another thing imposed on newbies, which goes against the general idea of this thread of simplifying things.
Just to make it clear @Bodigrim , I agree with the sentiment that we should not go back to sandboxes, but I do think that we should change cabal (lib, tool and format) to decouple building from publishing, make it easier to start a new project and make it easier to do as much as possible without having to manually edit the cabal file (without also installing other tools).
4 Likes
I second @andreabedini’s request for feedback from students and educators.
On the topic of newcomers to Haskell being diverse, the Stack project finds it useful to have an audience in mind for its documentation, which is currently:
A person who is about to begin to study computing as an undergraduate but who has not previously coded using Haskell. That person may be familiar with one popular operating system but may not be familiar with others.
Prompted by this discussion, I am part way through a re-review of the form and content of Stack’s online documentation at The Haskell Tool Stack. Does it meet that hypothetical person’s needs? All feedback, gratefully received - here, on Matrix, or at Stack’s GitHub repository.
3 Likes
I can provide one data point here, based on having taught Haskell-based courses since 2017. My teaching experience is at non-selective US state institutions, so my students have been diverse in terms of their background, technical expertise, and motivation for pursuing a CS degree.
I’ve always provided students with scaffolding for their assignments, nowadays using GitHub. That scaffolding includes the relevant .cabal file. We tell students to use cabal repl to explore their code. None of this has ever caused problems.
In final projects, I have given students the option of using additional libraries, and pointed them to the Cabal documentation. Several (motivated) students have followed this approach, and did not report problems using Cabal.
In olden times, I had to tell students how to install Haskell on their machines. My instructions seem to have switched from the Haskell platform to GHCup in 2022. More recently, I have encouraged students to use Docker, via VS Code, and now to use Codespaces. (Gitpod would work as well, but would have required more manual plumbing and cooperation from our IT folks).
The primary issues we had to debug were library conflicts (every so often, someone managed to get GHC and Python to conflict on Windows IIRC) , and a brief bit of nonsense with the first Apple Silicon devices. We did not run into issues with students being unable or unwilling to follow either the Haskell platform or GHCup installation instructions on any operating system.
To summarize: in my teaching, the mechanics of setting up GHC and interacting with Cabal fall primarily on the instructor and course staff. It is easy enough to set up student assignments in such a way that only students independently interested in learning about Haskell and its ecosystem have any need to interact with these tools. Finally, while I may be ahead of the curve in switching to hosted development environments, I suspect this will very shortly be the norm in many educational institutions—the reduction in overhead and increases in accessibility are just too much to be ignored.
10 Likes
This is a return of the repressed of course. Back when, students were expected to development at the lab, not on their personal machines, and lab machines were exactly these sorts of hosted development environments – another advantage being that they act as equalizers, ensuring students all have the same access to the same resources to do their work.
2 Likes
There are dueling accessibility issues here: hosted environments give everyone access to the same setup, but at the cost of requiring access to the hosting service.
The nice thing about using Codespaces or Gitpod is that your hosted environment is Docker-based. So students are free to: rely on the hosted environment, run virtual machines locally (VSCode has very nice support for this actually), or recreate the required environment on their own machines.
3 Likes
Thank you Garrett, that is the sort of experience I was hoping to hear from.
Ok done. I merely downloaded the .tar from Hackage; unpacked the .hs's into a dedicated folder/subfolders; compiled. It worked. No hell. I’m not seeing how all those cabal-install options would have helped.
Wise words. I’m kinda concluding it’s the “scaffolding” that’s the important part; the specific technology supporting it less so. Because …
On Hackage there seems to be a large amount of … emm … cruft: packages that were more “Hello World” experiments than anything widely useful; not maintained; don’t/haven’t recently/haven’t ever compiled. That’s where teaching-staff guidance would have helped.
So I’ve persuaded myself (personal opinion only) to eschew Cabal and all its pomps.
Yes, hackage is not a curated set of packages.
Mildly related: Maintainership standards · Issue #7 · haskellfoundation/stability · GitHub
I don’t pretend to know if this answer (arrived today) is correct, or is over-complicating the explanation/too much info; I would put myself in the category “not expecting to deal with this” complexity … really, ever [**]. This paragraph caught my eye:
This is not asking about the HLS you think it’s asking about. There is an
hlspackage on Hackage, but it is not the Haskell language server. That package is namedhaskell-language-server.
(There is indeed a package named haskell-language-server. There are also plenty of packages named hls-blah-blah – as far as I can tell, they all relate to haskell-language-server. I don’t see a package named bare hls. Ah, Hoogle tells me " [hls]: Haskell Lindenmayer Systems", not on Stackage, Deprecated.)
[**] When I was a professional programmer, I just cut code, unit tested, checked it in. There was a dedicated artefacts/version/distribution control team. Quite possibly I was present at their explanations parallel to that SO answer. If, so I glazed over.
“Is cabal-install stable enough yet that GHC should be inflicting it on newbies?”
No:
(…cabal -lib install: another one for the collection).