Oh yeah, I actually forgot that it does already exist. I’ve been treating it as unimplemented until it stops being a RebindableSyntax
hack.
This is exactly what I’d love to be able to say!
Great idea! I’ll see if I can integrate this into my in-progress project builder tool. Any suggestions on what comments it could mention for Haskell?
EDIT: Just thought of one that’s really important: telling beginners how to add new packages! That could help a lot with avoiding the abomination that is cabal install --lib
.
Do beginners not know to add a package to their cabal file? That feels like cabal 101.
EDIT: You know what, I just looked at some cabal docs and this is nowhere to be seen prominently in the beginning. This should be in the README.
On the FP Discord, we deal with beginners all the time who have tried to cabal install
libraries. I have a fair bit of sympathy for them — it’s the kind of thing which sounds like it should be right, but isn’t. (cabal install
is really confusingly named for people who are unfamiliar with the Unix ecosystem.)
cabal install
is a really nice tool for installing exes though. I use it all the time, even on NixOS!
Indeed, it’s great for exes. No surprise there — that’s exactly what it’s designed for! But using cabal install
for libraries may have unexpected results, and cabal install --lib
is basically guaranteed to break your Haskell installation unless you know exactly what it’s doing.
Oh cool, that I didn’t know about. Thanks for the tip! I’d still rather have an implicit module created for me automatically so I could just do
modifyCompany company = company { Company.name = "new name" }
Or if it just knew what record I wanted, I’d be ok with that too. Sounds like thats what OverloadedRecordUpdate
does, but I suppose I should shy away from that for now
No, they dont. It took me a good long while to figure out how to add packages to cabal initially. The docs were scary and vast, and even once I figured out where to put them, it took me a while after that to figure out what exactly the package name was. I assumed at first maybe it was the module name, and then eventually learned its the name used in the url.
E.g: In https://hackage.haskell.org/package/yesod-persistent
, the package is yesod-persistent
.
I know that may sound dumb, but that was a big struggling point for me when I first started. I probably spent a day trying to figure out how to add dependencies. Other package managers like dart and cargo tell you in the packaging site how to install it.
e.g: crates.io: Rust Package Registry
or flutter_form_builder install | Flutter package
or react - npm
or NuGet Gallery | Newtonsoft.Json 13.0.3
Obviously, in our current state, hackage can’t just drop a command like cabal add yesod-persistent
because it doesn’t exist, but it’d be great to see that type of thing
I’ll note that Cabal does have a Getting Started guide. It should be more obviously advertised, though.
I hadn’t actually seen this. It is accessible within three clicks from the downloads page, but maybe that’s too many. I’d like to see it be more prominent, though it would invite the usual debates around whether all build tools are equals (personally, I’m increasingly resolute that in order to streamline the experience for new users, we need to kill Stack and better integrate Stackage in to Cabal…).
Tldr… I use base < 5
for essentially all my projects and generally stack for building. So as long as I have a matching HLS version it usually just works, but I agree HLS can be finicky to get working for a project sometimes.
+1 for a cabal add
command (like cargo has).
Exactly like that! Alas, by and large, Haskell beginners don’t know about Flora…
GHCup also has a one-click link to their “First Steps” guide which is very similar to Cabal’s Getting Started but covering more tools than just cabal.
Wow… I had no idea that existed. And it’s already pretty prominent on the GHCup homepage. I guess people (myself included) just don’t read things properly.
Oh wow! Flora is fantastic. This is a much cleaner interface. Much less cluttered and shows the important bits like how to add the cabal dependency right at the beginning. I did not know about this.
I’m not sure if this exists or not, but is there also a way to tag packages with some type of category? One of the other issues I had with package search in haskell when I first started was that I didn’t know what packages I was looking for. I remember jumping into hackage and searching for “rest” or “http” looking for a web framework, or “sql” looking for a database lib. I never found anything like yesod, servant, or opaleye using this style of searching. I think it’d be a great way to boost discoverability of packages
Edit:
Ah nvm! I just noticed the “categories” blatantly staring at me in one of the packages.
Edit 2:
It would be nice if you could type category names on the search bar and it brought up relevant packages. And I think we need more tags on packages. Not just database
, but also sql
, nosql
, sqlite
, rest
web
, etc.
It does.
(and apparently I have to add another sentence to satisfy Discourse…)
Like this? https://flora.pm/categories/data-structures?
Having the category page is useful, but if you type a category directly into the package search, it doesn’t bring up results based on the category, it strictly does a package name search.
Incorporating categories matching the search query into the results would really boost this thing to the next level. And then adding more tags to each package to increase the likelihood of finding relevant results
This does work on Hackage, though: https://hackage.haskell.org/packages/search?terms=data-structures
Yea I guess it does. I’m learning a lot from this thread haha.
Btw I just wanted to say “thank you!” to everyone that’s taken part in this conversation, and the community in general. I feel like I’m acting like a baby or ungrateful with all the complaining I’m doing. I really appreciate all of the hard work everyone has put towards improving tooling and QOL, and I think the results are quite tangible. I feel very positive about the future of Haskell