Manager for Haskell Cabal files

[ysangkok]

The Cabal build system supports version constraints, see example. It would be nice if Renovate could parse the Cabal files and bump the version bounds contained within. @secustor requested on #31434 that I start a discussion for this:

This needs a discussion first for the manager part

Cabal doesn't specify the versioning scheme that packages should use, but some operators are designed for use with PVP , for example the ^>= operator. It would be nice if Renovate supported PVP, but strictly speaking this is a separate concern from adding Cabal file parsing and dependency extraction.

I am a committer for the Hackage-server, which proves a web API that the Cabal client command line tools interacts with, e.g. the commands in cabal-install. Hackage has a JSON endpoint that lists versions available for a package, e.g. https://hackage.haskell.org/package/base.json . However, this is also not really relevant to the discussion of the manager, since this functionality would be covered by the datasource (subject to future discussion, but see the PR for an idea of how it could work). See also #8187, which has a discussion on a Hackage data source.

Have you had a look at the Cabal file parsing code in the linked PR, and do you have some ideas for how to implement a parser for the format? I would love to hear them.

Have you looked at the tests in the PR? Do you think they adequately test the minimum functionality? Let's start out with a solid MVP such that we can iterate on it with smaller PRs. What do you consider the most important features to support in a Cabal file? Does the linked PR attempt to handle those MVP features?

[secustor]

Cabal doesn't specify the versioning scheme that packages should use, but some operators are designed for use with PVP , for example the ^>= operator. It would be nice if Renovate supported PVP, but strictly speaking this is a separate concern from adding Cabal file parsing and dependency extraction.

We would need a haskel versioning implementation for that in any case as combining multiple ranges with && is not used by any other system right now.
So it is fine if it doesn't support PVP in the first iteration, though we have to document this.

Have you had a look at the Cabal file parsing code in the linked PR, and do you have some ideas for how to implement a parser for the format? I would love to hear them.

Yes, I have glanced through your code.
You should take inspiration of the other managers which use it such as bazel, though this is at a later stage.

The order of PRs is:

• versioning
• datasource ( as datasource a defines a default versioning )
• manager ( as the extraction results define a datasource to be used )

With that ordering users can also already use the data even without the manager via custom manager.

Have you looked at the tests in the PR? Do you think they adequately test the minimum functionality? Let's start out with a solid MVP such that we can iterate on it with smaller PRs. What do you consider the most important features to support in a Cabal file? Does the linked PR attempt to handle those MVP features?

It makes sense to start with a subset features, like you do, though foundation has to be still reliable and well tested.

Regarding tests, look at our development docs in /docs/development and look at other PRs which recently implemented new integrations to see how code looks like that we are feeling comfortable to merge.

Finally there shouldn't be any code changes for the general processing logic needed ( lib/workers ), that makes me suspicious that you do something which is not needed.

[ysangkok]

Thanks for your comments. As suggested I have started a discussion on the requirements for versioning. This code will not need any modification to lib/workers. Discussion is at: #31663

I will return to this discussion once I finish versioning.

[ysangkok]

combining multiple ranges with && is not used by any other system right now.

As far as I understand from the semver cheatsheet, semver does support ranges, though the && is implicit. Does Renovate currently aim to support these? It seems like supporting ranges across the codebase should be the first step. As I understand versioning, the versioning only covers part of this, since there seem to be assumptions that version bounds are for specific versions, and not ranges. For instance lookup/index calls versioning.isValid, but isValid for semver is defined to not accept ranges:

describe('modules/versioning/semver/index', () => {                                                                                                           
  it.each`                                                                                                                                                    
    version                                          | expected                                                                                               
[...]
    ${'1.2.3'}                                       | ${true}                                                                                                
[...]
    ${'~1.2.3'}                                      | ${false}                     
    ${'^1.2.3'}                                      | ${false}                     
    ${'>1.2.3'}                                      | ${false}

The reason I patched auto-replace was because I couldn't get it to accept the range that I outputted. If we tackle range support in a generic fashion, you're of course right that I shouldn't need to make any changes to lib/workers, which contains auto-replace.

It makes sense to start with a subset features, like you do, though foundation has to be still reliable and well tested.

I totally agree, but I am not sure what would be considered a reasonable subset. For example, I am worried that adding range support across the codebase might be too hard. Maybe it would make sense to add just NPM-style bounds first with semver. As far as I understand, this means that there would be no versioning changes. Is this correct?

One issue with adding PVP support, is that getMajor is defined in e.g. versioning/generic.ts to return an int. But in PVP, there are two numeric components in the 'major' part of the version. That's something that makes me hesitant to add PVP, and even if Renovate only supports semver ranges, and puts the updates in the wrong minor/major bucket, it would still add a lot of value.

But all of these concerns do not really affect the data source. I could add the data source, specifying semver as its versioning. It would be correct for some packages, incorrect for others. But it would be a start. Would this be acceptable? Or do you think one of the other previously mentioned areas should be done first?

[rarkins]

As far as I understand from the semver cheatsheet, semver does support ranges

Unfortunately this is incorrect. Semantic Versioning, as defined in https://semver.org/, has no concept of ranges/constraints at all. All ranges/constraints you see are adaptations and wrappers of semver, such as by npm.

though the && is implicit.

In npm semver, and probably most other adaptations, the && is implicit.

Does Renovate currently aim to support these?

Not as part of Renovate's "semver" versioning, because as mentioned above semver doesn't support ranges. Renovate already supports multiple semver flavors (npm, cargo, go, composer, etc) too, but none of those need &&. If there was a need to support && for a new flavor of semver like Haskell then yes.

It seems like supporting ranges across the codebase should be the first step.

If Haskell's versioning differs from other existing flavors of semver which Renovate supports then it means a new "versioning scheme" needs adding in Renovate for Haskell. Adding a new semver versioning flavor is reasonably well documented and precedented.

[ysangkok]

In my PR, I did add a stab at PVP support, see same-major-pvp/index.spec.ts. Is this broadly the right structure? It sounds like it might be supposed to contain more range logic. I could expand it to have stuff like >=1.2 && <1.3 in the range arguments. I could also have it omit the &&, such that it would be closer to NPM syntax. In the PR I submitted, I had the auto-replace module insert the && where needed, to keep the versioning module oblivious to the details of the encoding of the boolean expression. But it might be cleaner to just have the versioning module operate on snippets that are also valid snippets of Cabal file syntax. So how does that sound, I could make a new PR, with just versioning, that contains all those tests, and more (related to ranges). Depending on how difficult it would be, I could also support || and parens and version sets. Would it be ok for an MVP only to support e.g. expressions of form >=X && <Y?

[rarkins]

I'm not aware of the requirements for this new versioning so can't comment further. I suggest starting a new discussion on this versioning where we aim to capture all the requirements and ideally how it's similar or different to any existing semver flavors. Once I understand the requirements then I'm better placed to comment on the solution or suggest a solution.

Regarding your last question, it's perfectly ok for a versioning to support only a subset of syntax initially, as long as it's documented. Unsupported syntax would then be ignored (no updates provided) with skipReason=unsupported-value

[ysangkok]

Ok, so I think I have a fairly clear understanding of how the datasource should work, which is the next step after #32298. But the manager (the subject of this discussion) is more tricky.

The main reason is that Cabal files use a custom whitespace sensitive syntax. See the multi-line value example. I see no way around writing a custom parser in the manager, which involves a bunch of code.

My draft manager currently the following string-based approach:

1. searches for the build-depends: in *.cabal files. This is suboptimal because it would find false positives, like e.g. if somebody mentions build-depends: in the package description (which is just a long string). But OTOH one could argue that this isn't likely to happen in practise.
2. After finding the index, it uses string functions to find the the extents of the 'block'. In the example linked above, it would include those lines (the ones that start with ,).
3. Then, it would split on comma and construct PackageDependencys. At this point, generic code takes over.
4. Code like lookup.ts would use the Hackage datasource in conjunction with the PVP module to determine which updates are available

The reason I opted for this approach, is such that Renovate doesn't include parsing code for structures it doesn't need.

A hypothetical alternate approach would be to develop a full Cabal parser that would parse stanzas/sections (e.g. library, common, executable) and construct an general-purpose AST. This would be a lot more code, and I think it makes little sense since I don't know of any actual package that wouldn't be parsable with the string based approach, which has less code.

There is a regression test suite in the Cabal people that I have tested with, and the string-based parser can parse all of it.

So please, if you have a preference around Cabal file parsing, please let me know. Otherwise, I'd submit something similar to my draft once the Hackage datasource has been merged.

[ysangkok]

I have now submitted a PR which implements what is described here, it is at

• feat(manager): add Cabal/Haskell manager using Hackage/PVP #33142

[ysangkok]

I just noticed the customManager for JSON:

• feat(managers/custom): generic manager for json files #32784

When YAML support is added to this (which seems planned), it should allow for parsing a subset of package.yaml files. Given that PVP has already been merged, this means that only Hackage would need to get added before some real world testing could happen:

• feat(datasource): add Hackage datasource #32944

The customManager for JSON includes examples which split up a string with JSONata, which I think should also allow parsing stuff like base >= 4.10 && <4.11 into package name and version.

I'd note that a proper cabal manager would still be useful, since not all packages use Hpack to generate the Cabal file. I am just pointing out that there is this additional way this could get used.

[ysangkok]

Fixed already:

• fix(manager/haskell-cabal): Handle comments in Cabal file #33695
• feat(datasource/hackage): Detect deprecation status #33778
• How to run CI with --constraint when Renovate updates bounds?
  • Add hints on Renovate usage haskell-actions/setup#113

Bugs:

• Renovate shouldn't mess with ranges it can't understand: haskell-servant/servant-lucid@cb6cd03
• PR titles can be wrong e.g. when there are trailing zeros: Update dependency semigroups to v0.2 haskell-servant/servant-lucid#35

Ideas for upcoming features:

• Add timestamp/changelog to release on Hackage JSON structures such that minimumReleaseAge could be used. See comment
• Support all rangeStrategies:
  • Support pinning (e.g. using == to pin to exact version)
  • Support replacing (e.g. just one major version, but accept all versions there. Is this ^>= or is it just >=X.Y && <V.W?)
  • Support bump (Is this ^>=X.Y.Z?)
• Support bumping GHC/cabal-install versions in GitHub CI: https://github.com/haskell-actions/setup
• Update index-state in cabal.project
• Update source-repository-package in cabal.project

Ideas maybe not for Renovate:

• Release bot
  • https://github.com/haskell-actions/hackage-publish
  • Would be nice to deduce versioning automatically, also based on trailers: https://alchemists.io/projects/milestoner

[ysangkok]

One option would be to use postUpgradeTasks. Sadly, this means that we'd have to set up a self-hosted Renovate instance, since those tasks don't work for the Renovate SaaS App.

Another, more convenient option, would be to have the Haskell Github CI action recognize that a PR is a bounds bump. It would then invoke cabal test with e.g. --constraint=network==3.2.1, if the newVersion is 3.2.1. This seems like the most convenient option, but it is also a bit icky because we need some kinda wonky recognition of what Renovate is doing.

Cabal actually has a feature to commit constraints into cabal.project, which seems good since it allows for the repo to commit to the versions getting tested. This feature is supported by Haskell-CI, see example. The way Haskell-CI works, is that it generates the Github Actions CI file using a Haskell program. This is also something that could be done with a postUpgradeTask.

So I am a bit torn on which direction to go.

• It seems like the short term solution would be to add Renovate recognition support in the Haskell Actions CI
• the long term solution would be to define an ABI for a data format which lets Renovate attach metadata to a PR saying "i am bumping this dependency to that version, CI suite, please make sure it works". The advantage of a format like that is that it could also work on platforms like Sourcehut, Gitea, Forgejo, Gitlab, Bitbucket and so on.
  • A Haskell-CI runner should be able to detect that data and
    • either add it permanently to the cabal.project, and run Haskell-CI to generate a new config to run forever
    • or run a one-off test with the new dependency

It seems infeasible for Renovate to contain all this logic, which is why it makes sense to decouple the updating of the CI. Renovate isn't really a test runner or a release bot.

[wolfgangwalther]

It would then invoke cabal test with e.g. --constraint=network==3.2.1, if the newVersion is 3.2.1. This seems like the most convenient option, but it is also a bit icky because we need some kinda wonky recognition of what Renovate is doing.

But even then, I might not be testing my code, but the constrained network dependency. How it works together with the other constraints in my project.

Wouldn't we quickly end up with deadlocks? I.e. the PR for dependency A only works with an updated dependency B. But updating dependency B would also only work with the updated A. Maybe we'd need to do that with --allow-newer at the same time. Couldn't find out quickly, how --constraint and --allow-newer interact, though.

Let's assume --constraint=network==3.2.1 --allow-newer=all would work as expected, i.e. allowed newer for everything except network... I think that could work.

the long term solution would be to define an ABI for a data format which lets Renovate attach metadata to a PR saying "i am bumping this dependency to that version, CI suite, please make sure it works". The advantage of a format like that is that it could also work on platforms like Sourcehut, Gitea, Forgejo, Gitlab, Bitbucket and so on.

Yeah, that would be cool. That would have many more benefits, because I could run my very own specialized CI tasks for certain updates. As part of CI, not as part of postUpgradeTasks (those have always been a bit flaky / annoying for me on my self hosted renovate instance...).

[wolfgangwalther]

Let's assume --constraint=network==3.2.1 --allow-newer=all would work as expected, i.e. allowed newer for everything except network... I think that could work.

Except for those cases, where newer versions are not picked because they are required, but just because they are available.. and they themselves fail the build.

Might be possible to work around with --preferences=..., but this doesn't seem to be a simple thing to do...

[ysangkok]

Wouldn't we quickly end up with deadlocks?

I don't think I understand the scenario you're imagining. But I mainly just want to automate the bound bumping I have been doing for years, mostly to keep things in Stackage Nightly. That bumping only involved constraining a single package. A sign that this practice is widely accepted, is the fact that the Hackage Trustees will make bump revisions if you have demonstrated that it works with --constraint on a single version of GHC. They consider this sufficient testing.

In all of those years, I haven't encountered a deadlock situation yet, so I wouldn't say that it is common. If tests fail, people always have the option of figuring out what happened themselves. Before I announce this Haskell support in Renovate more widely, I was thinking of adding support for minimumReleaseAge. MinimumReleaseAge should massively increase the possibility that libraries have become compatible.

It's commonly known that the wide Haskell version ranges cause a combinatorial explosion. If I, or anyone else, adds replace, bump or pin support to the Cabal code in Renovate, we could give people an option of an alternate strategy. Pinning is very common outside of Haskell, for example Renovate originally was intended to default to it.

This shouldn't actually be hard to add. But it goes against the current culture, so I'd rather prioritize the less radical proposals, like e.g. automating the presently used philosophy (widen), e.g. with a Hackage release bot.

But if you want make absolutely sure that people are only building with specific versions, pinning would be the way to go, and it is already supported by our existing test runners like haskell-actions/setup.

[ysangkok]

@wolfgangwalther Here is a way that you can pass the new version to cabal test:

1. You can embed the new versions in a git trailer. Add the following Renovate configuration option:

   "commitBody": "New-Versions:\n{{#each upgrades}}  {{{depName}}}=={{{newVersion}}}\n{{/each}}",
   

   You can optionally use distinct if you want to avoid duplicates. But they don't hurt, so whatever.
2. Now, during your CI run, after checking out the PR with the Renovate commit, you can extract these versions from the commit body using

   git log "--format=%(trailers:key=New-Versions,valueonly=true,separator=)" -1
   

   This will yield a whitespace separated list of pairs like e.g. network==1.2.3 other-dep==4.5.6.
3. You simply just have to prepend -c before each element, and you can pass it to cabal test. So the final command will look like e.g.
   cabal test -c network==1.2.3 -c other-dep==4.5.6

Example commit: https://github.com/ysangkok/diagrams-builder/pull/7/commits/2d9211e2785eedaee621fe7c5ad4f7b90b0a54f3 with trailer

Example Github Actions run that failed because the required base constraint can't be satisfied: https://github.com/haskell-github-trust/pureMD5/actions/runs/12856584561/job/35843424088?pr=14

[wolfgangwalther]

@ysangkok do you think it would be possibly to preserve formatting when updating?

See for example: https://github.com/PostgREST/postgrest/pull/3846/files

It seems unnecessary to remove all the whitespace, ideally it was only the version itself being replaced.

[ysangkok]

It's possible, but honestly the other proposed features are more interesting to me...
Retaining the whitespace won't be perfect anyway, because some people will be aligning the && across lines, other people will align the dot in the lower and the upper bound, and so on...
To get it perfect would require way too much effort...
But if you have ideas, I'd be happy to hear them.

[wolfgangwalther]

Well, yeah, I'm not asking to introduce new whitespace, so that the previous formatting is kept. I don't exactly know how this works, but wouldn't the whitespace in this case just need to be moved out of the part that is replaced? I.e. I think the capture group for the replacement seems to big too me.

[wolfgangwalther]

The underlying issue of formatting could also be solved by a formatter. Will look into https://github.com/phadej/cabal-fmt when I have time. Ultimately, I just want some kind of consistency, not necessarily this formatting we have right now.

[ysangkok]

If you just want consistency, I'd recommend just using

, foo >=1.0 && <2.1
, bar >=4000.1 && <4000.2

That style would be maintained by Renovate. Mind that you have to use a high enough cabal-version to allow the preceding comma on the first line.