Haskell support

[hasufell]

The Haskell ecosystem often suffers from outdated package bounds. Various attempts have been made to improve the situation, but ultimately developers need a convenient method to update their bounds.

Haskell uses PVP for versioning (which is somewhat similar to semver). It then uses Cabal for package and version management (similar to rusts cargo). Packages are shared and uploaded on hackage.

I think the main hurdle of adding support here is that the cabal file format is custom. Obviously there exists a haskell parser in the Cabal library. There also seems to be some documentation on the file format. I'm not sure if that's enough to re-implement a parser or if a regexp solution would be possible.

[jurre]

Thanks for opening this issue @hasufell.

Unfortunately it might be a while before our team has the capacity to pick up a new ecosystem like Haskell.

However, when we do get around to it, I think our preferred way to deal with parsing the Cabal files would be to write a native helper, like this one in Haskell, and shell out to that, instead of trying to parse the file and keeping up with any changes made to the format.

[expipiplus1]

It's worth noting that many Haskell packages are described in YAML using the schema described here: https://github.com/sol/hpack

[hasufell]

It's worth noting that many Haskell packages are described in YAML using the schema described here: https://github.com/sol/hpack

Hpack is an optional tool that generates cabal files. It isn't a standard though.

I guess it could be debated whether users also want their hpack files to be updated. But I believe the main focus should be cabal files.

[KiaraGrouwstra]

related thread

[KiaraGrouwstra]

for transparency, I opened a PR for my wip attempt to add haskell support at #3195.

[brightly-salty]

With regard to the hpack issue, I think if it would be annoying to have the cabal updated without the package.yaml being updated, because it will be overwritten the next time you build. I feel it would be a good first step to focus on package.yaml files first before or in addition to .cabal files being added and updated.

[hasufell]

I feel it would be a good first step to focus on package.yaml files first before or in addition to .cabal files being added and updated.

package.yaml aren't canonical files that are properly specified. Haskell has only one file format for building packages: cabal. Everything else is custom stuff that some ppl use, some don't. Everyone uses cabal files.

[brightly-salty]

I agree that everyone uses cabal files, but I think that updating cabal files without updating package.yaml files would break many people's workflows. For example, I don't keep my cabal files in git because it results in needless noisey changes whenever a file is deleted or created, and instead just keep my package.yaml in git. Maybe it would be good to have a configuration option with this, but I think universally updating cabal files without regard to package.yaml files would deter me from using dependabot on my projects, and may do so for others as well.

[hasufell]

For example, I don't keep my cabal files in git

That's bad. Please commit them. Otherwise you're breaking cabal users ability to use your repository via source-repository-package stanza.

Note: I'm not advocating against supporting package.yaml, but I think it's an unreasonable proposal to support a 3rd party tool before the canoncial package definition format.

[Anton-Latukha]

https://github.com/dependabot/dependabot-core/issues/2745#issuecomment-845236742

but I think that updating cabal files without updating package.yaml files would break many people's workflows.

There is some puzzlement. An the implicit assumption that people that use HPack would somehow be taken hostage & forced to merge Dependabot automation for Cabal in their repositories. For Dependabot Cabal support to break their HPack-configured projects.

I am an HNix developer - I do not conceive to ask to support Cabal Nix & NixPkgs integration setup before regular Cabal.

Every packaging tool in the Haskell system depends on a minimal Cabal <-> Hackage infrastructure loop.

---

About not including Cabal in source

Not including Cabal description into source tree, but then it somehow magically appears for Hackage upload & source tarball downloaded from Hackage. & now pipeline & maintainers downstream are puzzled - why tarball builds but the source from the official repository does not & why there is a file difference in those, they need to decipher what gets injected behind the scenes. It also means the project is not reproducible, so https://reproducible-builds.org/projects/ & https://tests.reproducible-builds.org/debian/reproducible.html. As the whole Haskell ecosystem (& even NixPkgs `haskellPackage` set - depend on Cabal package description format. Currently.) - because everything depends on Cabal - please do not exclude Cabal descriptions from the source code, & if using HPack - just treat Cabal file as a state update details file that needs to be included in source code commits from time to time.

[Anton-Latukha]

The Haskell ecosystem often suffers from outdated package bounds.

I resonate strongly with that idea. Ecosystem would benefit immensely just by having a default way of notifying maintainers & suggesting updates. Some community members have ~100+ packages, that was created by not well supported & there always would be such thing of people spreading thin. For old history to not repeat itself - the default way of automation would be tremendously beneficial. If someone up the stack can merge a new base bound without searching them out through social networking.

---

Because of Haskell strong typing system & referential transparency of the language - FFI with Haskell can give the highest guarantees of stability.

I noticed that Dependabot formerly had docs on FFI. & it currently seems to require https://github.com/ffi/ffi somewhere inside package descriptions in the bundler. If GitHub can not provide Haskell support - the next best option for both sides is community-managed implementation through FFI.

[jurre]

Fwiw we're starting to think about a way to push down a lot of the functionality that is currently implemented in dependabot-core into the package ecosystem itself, leaving dependabot-core as a thing wrapper around the native functionality. While this is still mostly in an idea/prototyping stage, I do think that once something like that lands it would open up support for more ecosystems again.

Once we have something substantial to share I'll loop back in this thread.

[eborden]

@jurre I'm curious if any of those ideas have crystallized? Are they documented anywhere?

[jurre]

@jurre I'm curious if any of those ideas have crystallized? Are they documented anywhere?

Not quite there yet but we're working on it, I'll make sure to update here when we have something to share

[domenkozar]

@jurre any updates?

[domenkozar]

Also worth keeping an eye on: https://github.com/renovatebot/renovate/issues/8187

[ArturGajowy]

@jurre any updates on supporting more ecosystems / outsourcing the support?

[mihaimaruseac]

Any update here? I was mistakenly thinking that Haskell support was already implemented :(