Convenience in the Haskell ecosystem

#103

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.

#104

It does.

(and apparently I have to add another sentence to satisfy Discourse…)

1 Like
#105

Like this? https://flora.pm/categories/data-structures?

4 Likes
#106

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

1 Like
#107

This does work on Hackage, though: https://hackage.haskell.org/packages/search?terms=data-structures

#108

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

8 Likes
#109

It’s not obvious at this point as to whether Flora.pm is fully ready to be a replacement for Hackage. It is much, much cleaner; the interface is much nicer, but it still has to point to Hackage for documentation.

But yeah, on Discord I mentioned something to the degree of “Wow” when I first saw Flora.pm. Hecate’s site is a magnificent effort.

2 Likes
#110

I’ve got an easy answer to that one: It is not. :slight_smile: It’s a great thing if you need a more effective view of packages, but documentation is not self-hosted yet.

When it’s ready to replace hackage you’ll know it because you’ll be using it.

But yeah, on Discord I mentioned something to the degree of “Wow” when I first saw Flora.pm. Hecate’s site is a magnificent effort.

Cheers!

8 Likes
#111

If we got cabal add functionality then perhaps it would be nice to have an HLS plugin where when you type an import and it’s not exposed in a dependency, HLS can have a code action that adds the appropriate dependency to your cabal file. It should even be able to figure out what component(s) need it based on the file you’re editing. Potentially there might be multiple code actions if there happen to be multiple packages exposing a module with that name.

4 Likes
#112

I’m starting to feel that a lot of really cool functionality is waiting on an exact-printing Cabal parser. It would be really nice to get a more coherent development effort around that. I don’t know what organisation exists around such things, though — is this the kind of project the Haskell Foundation would be willing to support?

7 Likes
#113

If you’re talking about this cabal add idea I think I’ve seen mentioned a few times, I think that’s waiting on more than just an exact-printing parser. Cabal files aren’t as simple as package.json or whatever; a Cabal file can have multiple libraries, executables, test executables, benchmarks, etc., each of which has its own set of dependencies. And all of those things can share dependencies via common stanzas. I don’t know what one would expect a cabal add to do with any moderately interesting Cabal file.

Maybe you intend to develop a simplified subset of the Cabal language for newbies, and then cabal add works exclusively with files written in that subset? But now you’re venturing a lot closer to CRA territory, where the training wheels have to be taken off when the baby user starts asking perfectly reasonable questions like how to expose the same set of GHC extensions to your app code and your tests.

1 Like
#114

One option would be for it to interactively ask in which section(s) the dependency should be added. Or it could take command-line parameters (cabal add --lib, cabal add --exe, etc.), and abort in ambiguous cases. Either way, I don’t see this as a particularly huge problem — there are many options.

But, as it happens, I’m not just talking about cabal add. Even within current Cabal, people have mentioned issues with cabal gen-bounds. Then there’s @MorrowM’s great idea of letting HLS make changes to the Cabal file based on dependencies. And so on and so forth.

1 Like
#115

I’m starting to feel that a lot of really cool functionality is waiting on an exact-printing Cabal parser. It would be really nice to get a more coherent development effort around that. I don’t know what organisation exists around such things, though — is this the kind of project the Haskell Foundation would be willing to support?

There’s a pretty complex fleshed out discussion on a cabal ticket, which includes some recent activity of a few people interested in exploring this: Meta: Exact-printer Mega-issue · Issue #7544 · haskell/cabal · GitHub

If there was a person with demonstrated capacity and knowledge who made an HF tech proposal to get funding to do this, that would certainly be something the tech advisory group would seriously consider.

10 Likes
#116

True, I’d forgotten that this issue exists.

#117

About the cabal exact parser, there’s one standing partial solution right now.

This is, iirc, missing the ability to prune data after the main text? Morever, I’m not sure about its general reliability; the parser tends to allow a lot of invalid Cabal files through (I’m told barring invalid Cabal files isn’t an objective). I think the HLS project is looking for someone to complete it, and this might be the fastest way to get an exact-parser.

I have my own, but it’s sort of embarrassing (I can parse whitespace and comments, and everything else as “raw”). GitHub - liamzee/flatparse-cabal-exact: A flatparse-based library for exact-parsing cabal files.

As for the project itself, a very skilled Haskeller could probably push out a prototype in 25-50 hours, then test and refine it in another 25-50 hours; i.e, I wouldn’t consider the parser that challenging.

The bigger problem, rather, is the information in the Github thread; that is to say, the Cabal file format seems eccentric, and is defined by the parser’s behavior.

The Cabal codebase dates all the way back to 2003, at the very least, and it’s a bit hard to be onboarded onto. Actually building a high-quality parser requires going through a medium-large codebase, understanding how the parser is called, and how the parser works, and the Cabal megarepo itself is eccentric:

It seems that originally, the Cabal executable (cabal-install) didn’t exist as a separate package, and Cabal was usable on its own via Setup.hs. cabal-install is actually hooking into Cabal, just like Stack, and there’s a bit of kludge in doing so; it works, it works well, but the codebase is harder to understand as a consequence.

The fastest way to do it would be just to have someone familiar with the Cabal codebase and moreover, the Cabal parser, rig something up in a few weeks.

The second fastest way to do it would be to find a more skilled Haskeller than me to build the exact-parser, possibly based off VeryMilkyJoe’s version; I think it might take a month at most to understand the Cabal parser in its native context, understand it, then a couple of days of work to build the parser, two weeks, tops.

However, I’m still going to try to do it as a personal challenge. As I am seeking medical care right now, I have a lot of spare time, and suspect I might be able to get something decent by February at the latest.

If someone beats me to the exact-parser, I’ll still hopefully understand the Cabal codebase by then and be able to help improve documentation for it.

1 Like
#118

Let me quote @george.fst from another thread, since I think his comments are also relevant here:

1 Like
#119

Thanks for that great initiative. Speaking of convenience: I’m working on improving the documentation in the Haskell ecosystem and it would be really nice to automatically also get a space to host companion pages with tutorials, how-to’s etc to not clutter the regular Hackage code reference documentation pages.
E.g. a setup like Aeson is hard to read, hard to find (bad SEO) and hard to navigate.

Currently, if you want to separate these pages, you have to manage and host the companion pages yourself like Cabal or Yesodweb do, which many package maintainers may not have the time for.

10 Likes
#120

That’s also a goal for the development of Haddock, to have a space for guides that is integrated in the generated HTML. Feel free to send me a message if you want to collaborate on this. :slight_smile:

4 Likes
#121

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.)

1 Like
#122

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. No need to let the perfect be the enemy of the good. Maybe an implementer looking at it in more detail might be able to figure out reasonable behaviour for the more complex cases; if so, bonus.

2 Likes