# Abandoned Haskell Packages

**URL:** <https://discourse.haskell.org/t/abandoned-haskell-packages/9168>\
**Category:** Uncategorized\
**Created:** [March 27, 2024, 1:05pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168 "2024-03-27T13:05:35Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![enobayram](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/enobayram/32/1815_2.png) [@enobayram](https://discourse.haskell.org/u/enobayram)\
**Post date:** [March 27, 2024, 1:05pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/1 "2024-03-27T13:05:35Z")

</div>

Hi Everyone, I want to discuss an issue that I’ve been running into whenever I needed to upgrade GHC versions recently. I know from past experience that some projects only ever need to deal with GHC upgrades once every few years, but with my current hat, I end up doing that quite often with little projects at work that are still actively used but not actively developed.

The recurring issue I run into is that these packages resist GHC upgrades due to very minor problems. Like version bounds that are unnecessarily restrictive, or `when` not getting exposed from `mtl` anymore, or a failure due to a minor change in type inference, requiring a very simple change to the type class context of a function etc. If it were not for the bureaucracy of these failures happening in transitive dependencies, these would be 2-minute fixes.

Every time this happens, I want to open a PR to the problematic repo, but I find out that there’s already a PR from 6 months ago that fixes the GHC upgrade, sitting there completely ignored. So I end up adding the fix commit to the `cabal.project` file as a `source-repository-package` and move on, but I feel dissatisfied every time I do so. That’s because:

- There’s no way to share `cabal.project` between repos, so I have to do it in every such project
- `source-repository-package`'s aren’t actually that ergonomic, because they (and their dependents) are then considered local packages and that causes a variety of ergonomics issues (which I won’t go into).
- It saddens me to see that another one of our dependencies is abandoned and we should probably move away from it.

Putting aside the gloomy discussions about the decline of Haskell, I tend to think we have another problem in our hands here, because I see this happening to popular packages as well. I don’t want to name specific packages, but when this issue happens I see that somebody has opened the GHC upgrade fix PR within a few days of the release of the GHC version in question. I also see PRs from other contributors adding new features to the package, all ignored for the last few months.

Regardless of what might or might not be happening to the Haskell ecosystem at large, what I often observe with these popular packages seems to me like a bureaucratic issue. You could justifiably tell me that I should adopt these projects myself then, and I would indeed be willing to do so, but that’s not the kind of process one is typically willing to go through in the middle of upgrading the GHC of an occasionally developed project.

What do you think is the solution here? What do other language ecosystems do? What do you think is the best way I could try to improve the situation?

---

<div class="post-metadata">

**Author:** ![philderbeast](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/philderbeast/32/2489_2.png) [@philderbeast](https://discourse.haskell.org/u/philderbeast)\
**Post date:** [March 27, 2024, 1:15pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/2 "2024-03-27T13:15:03Z")

</div>

> There’s no way to share cabal.project between repos

This can be done via project imports. You can put the `source-repository-package` stuff to be shared in its own `.config` and import that.

---

<div class="post-metadata">

**Author:** ![philderbeast](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/philderbeast/32/2489_2.png) [@philderbeast](https://discourse.haskell.org/u/philderbeast)\
**Post date:** [March 27, 2024, 1:20pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/3 "2024-03-27T13:20:47Z")

</div>

Another option would be to import a common [`.dhall` configuration](https://github.com/up-do/unison/blob/add/updo/project-dhall/ghc-9.2.8/forks-external.dhall) for the repo fork and have Updo generate the project. The [Updo/unison/cabal.project](https://github.com/up-do/unison/blob/add/updo/cabal.project) example does this.

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [March 27, 2024, 1:21pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/4 "2024-03-27T13:21:32Z")

</div>

> [@enobayram](#):
>
> version bounds that are unnecessarily restrictive

~~I think you can ping [@hackage-trustees](https://github.com/hackage-trustees) on github to report version bound issues.~~ They can make a revision on Hackage to change the bounds.

~~Although I see not all trustees are part of that github org, for example @Bodigrim is not listed there but he has helped me with bounds issues before.~~

Edit: The right way to contact the trustees via GitHub is to:

> [@Bodigrim](#):
>
> raise an issue at [Issues · haskell-infra/hackage-trustees · GitHub](https://github.com/haskell-infra/hackage-trustees/issues)

---

<div class="post-metadata">

**Author:** ![LaurentRDC](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/laurentrdc/32/4950_2.png) [@LaurentRDC](https://discourse.haskell.org/u/LaurentRDC)\
**Post date:** [March 27, 2024, 1:24pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/5 "2024-03-27T13:24:16Z")

</div>

That is a tough situation indeed. The best we can do is to offer to put in the work, effectively become maintainers of packages which are important to us.

I recently encountered this situation for the `distributed-process-*` packages, which until recently, looked almost abandoned. I reached out to the maintainers and they were happy to onboard me so that I could help.

Similarly, you might want to reach out and offer to help maintaining the packages which are blocking you.  
Personally, I would follow the following levels of escalation:

1. Make PRs for the fixes you want;
2. If the PRs are ignored; offer to become maintainer;
3. As an extreme last resort, if the maintenance offer is ignored, there is a process to take over packages on Hackage. You can then maintain a fork and become the de-facto maintainer.

---

<div class="post-metadata">

**Author:** ![enobayram](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/enobayram/32/1815_2.png) [@enobayram](https://discourse.haskell.org/u/enobayram)\
**Post date:** [March 27, 2024, 1:24pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/6 "2024-03-27T13:24:20Z")

</div>

Thank you, I didn’t know about this! This might come in handy in the future, especially after refactoring the cabal.project files to extract the bits that will help downstream projects. That said, this still seems like a rabbit hole since it will probably have friction with `haskell.nix` and I can also imagine the `cabal.project` file of downstream repos conflicting with each other without a lot of care. Still great to know about this.

---

<div class="post-metadata">

**Author:** ![silky](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/silky/32/3555_2.png) [@silky](https://discourse.haskell.org/u/silky)\
**Post date:** [March 27, 2024, 1:25pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/7 "2024-03-27T13:25:08Z")

</div>

Yeah; it’s a nice comment and I’ve felt this pain.

For what it’s worth, I’ve found nix(pkgs) to be a nice storehouse of fixes of this kind; it’s not a system that works for everyone of course; but I think the general theme of fixing these things in an overlay is basically the way to go.

---

<div class="post-metadata">

**Author:** ![philderbeast](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/philderbeast/32/2489_2.png) [@philderbeast](https://discourse.haskell.org/u/philderbeast)\
**Post date:** [March 27, 2024, 1:29pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/8 "2024-03-27T13:29:04Z")

</div>

I developed Updo while working on an industrial project using haskell.nix, so they can work together. Updo has the option to generate everything in `cabal.project` without using imports. I can’t remember for sure but I think cabal project imports can be a problem if the version of cabal with nixpkgs/haskell.nix is too old.

---

<div class="post-metadata">

**Author:** ![enobayram](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/enobayram/32/1815_2.png) [@enobayram](https://discourse.haskell.org/u/enobayram)\
**Post date:** [March 27, 2024, 1:30pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/9 "2024-03-27T13:30:22Z")

</div>

We already use Nix to build our projects, but we also want them to build with cabal using the same dependencies, so we use `haskell.nix` to Nixify the Haskell packages, so I prefer to keep the tweaks at the cabal.project layer.

---

<div class="post-metadata">

**Author:** ![enobayram](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/enobayram/32/1815_2.png) [@enobayram](https://discourse.haskell.org/u/enobayram)\
**Post date:** [March 27, 2024, 1:36pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/10 "2024-03-27T13:36:58Z")

</div>

This sounds great, thank you for sharing Updo, I’ll definitely check it out.

In the grand scheme of things, though, this sounds like building a workaround layer on top of `cabal.project` (which itself is a workaround layer on top of the project’s `.cabal` file when you think about it) and the ideal case for the whole ecosystem would be for these issues to not be there in the first place. That’s why I wanted to open this discussion here hoping to push the needle for a solution to the root cause. Us experienced Haskellers can find one way or another to get our packages to build, but what saddens me is the deteriorating state of the package ecosystem due to the bureaucracy of pushing 1-line fixes.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [March 27, 2024, 1:38pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/11 "2024-03-27T13:38:46Z")

</div>

Even though it was [orphaned in 2018](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907114), Hugs continues to [exist in Debian](https://packages.debian.org/search?keywords=hugs&searchon=names&suite=all&section=all) largely due to _non-maintainer uploads_ - what would be required to support a similar mechanism for Hackage?

---

<div class="post-metadata">

**Author:** ![chreekat](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/chreekat/32/2669_2.png) [@chreekat](https://discourse.haskell.org/u/chreekat)\
**Post date:** [March 27, 2024, 2:40pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/12 "2024-03-27T14:40:53Z")

</div>

> [@atravers](#):
>
> what would be required to support a similar mechanism for Hackage?

I think it already exists and it’s exactly the process @LaurentRDC described!

1. Send PRs
2. Request Hackage revisions
3. Follow the Hackage takeover procedure

This might even be documented somewhere lol

---

<div class="post-metadata">

**Author:** ![Bodigrim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bodigrim/32/1457_2.png) [@Bodigrim](https://discourse.haskell.org/u/Bodigrim)\
**Post date:** [March 27, 2024, 8:20pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/13 "2024-03-27T20:20:23Z")

</div>

> [@enobayram](#):
>
> Putting aside the gloomy discussions about the decline of Haskell, I tend to think we have another problem in our hands here, because I see this happening to popular packages as well. I don’t want to name specific packages, but when this issue happens I see that somebody has opened the GHC upgrade fix PR within a few days of the release of the GHC version in question. I also see PRs from other contributors adding new features to the package, all ignored for the last few months.

@enobayram it would actually help if you were specific about packages and GHC versions in question. Stackage offers a reasonably complete snapshot for GHC 9.8, so it seems we talk either about less popular packages or about newer GHCs.

> [@jaror](#):
>
> I think you can ping [@hackage-trustees](https://github.com/hackage-trustees) on github to report version bound issues. They can make a revision on Hackage to change the bounds.
> 
> Although I see not all trustees are part of that github org, for example @Bodigrim is not listed there but he has helped me with bounds issues before.

GitHub does not relay a ping when you mention an organization. Also please do not ping me personally in such cases, but rather raise an issue at [Issues · haskell-infra/hackage-trustees · GitHub](https://github.com/haskell-infra/hackage-trustees/issues)

> [@atravers](#):
>
> Even though it was [orphaned in 2018](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907114), Hugs continues to [exist in Debian](https://packages.debian.org/search?keywords=hugs&searchon=names&suite=all&section=all) largely due to _non-maintainer uploads_ - what would be required to support a similar mechanism for Hackage?

Hackage supports NMUs, available for Hackage Trustees.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [March 27, 2024, 8:50pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/14 "2024-03-27T20:50:09Z")

</div>

> [@Bodigrim](#):
>
> Hackage supports NMUs, available for Hackage Trustees.

Thank you. However Debian allows anyone to provide an NMU. More importantly, the _“acquisition”_ of orphaned or dormant packages merely to remove a few bugs (rather than committing to long-term maintenance) is actively _discouraged_ e.g:

> [@](#):
>
> [5.12. Package Salvaging](https://www.debian.org/doc/manuals/developers-reference/pkgs.html#package-salvaging)
> 
> Do not start a package salvaging process when you do not intend to maintain the package for a prolonged time. If you only want to fix certain things, but not take over the package, you must use the NMU process, even if the package would be eligible for salvaging.

_As a last resort_ (having tried to contact the current maintainer/s, and so on), would it be possible to arrange for non-owners to contact the Hackage Trustees first for permission before the NMU?

---

<div class="post-metadata">

**Author:** ![Bodigrim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bodigrim/32/1457_2.png) [@Bodigrim](https://discourse.haskell.org/u/Bodigrim)\
**Post date:** [March 27, 2024, 9:06pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/15 "2024-03-27T21:06:56Z")

</div>

> [@atravers](#):
>
> _As a last resort_ (having tried to contact the current maintainer/s, and so on), would it be possible to arrange for non-owners to contact the Hackage Trustees first for permission before the NMU?

Sorry, I don’t quite follow. If you contacted the current maintainers, but did not receive a response within a month or two, in Hackage setting you are welcome to take over the package, even if only to fix a few bugs. Hackage NMUs are largely for cases when no one volunteered to take over or a quicker than permitted by takeover procedure response is justified.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [March 27, 2024, 9:33pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/16 "2024-03-27T21:33:13Z")

</div>

> [@Bodigrim](#):
>
> If you contacted the current maintainers, but did not receive a response within a month or two, in Hackage setting you are welcome to take over the package, even if only to fix a few bugs.

But for reasons seemingly unknown to anyone here, people just aren’t interested in taking over as package maintainers merely to remove a few bugs - instead they post a PR for their debugged version and move on (presumably back to their own Haskell project/s of interest). As a direct result, we’re now all here on this latest of posts about this topic.

The current situation with abandoned packages clearly is unsatisfactory, so I merely made a suggestion to try improving it: if it’s a bad one, bring forth the next suggestion…

---

<div class="post-metadata">

**Author:** ![Bodigrim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bodigrim/32/1457_2.png) [@Bodigrim](https://discourse.haskell.org/u/Bodigrim)\
**Post date:** [March 27, 2024, 9:36pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/17 "2024-03-27T21:36:44Z")

</div>

> [@atravers](#):
>
> The current situation with abandoned packages clearly is unsatisfactory, so I merely made a suggestion to try improving it: if it’s a bad one, bring forth the next suggestion…

As I said, I do not follow what’s your suggestion. Can one ask Hackage Trustees to make an NMU with a patch? Yes.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [March 27, 2024, 10:26pm UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/18 "2024-03-27T22:26:25Z")

</div>

> [@Bodigrim](#):
>
> I do not follow what’s your suggestion.

To allow anyone to make an NMU, subject to certain conditions - similar to what is allowed in Debian.

* * *

> Can one ask Hackage Trustees to make an NMU with a patch? Yes.

…this is the first time I’ve seen that option mentioned here (on Discourse).

---

<div class="post-metadata">

**Author:** ![chreekat](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/chreekat/32/2669_2.png) [@chreekat](https://discourse.haskell.org/u/chreekat)\
**Post date:** [March 28, 2024, 7:15am UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/19 "2024-03-28T07:15:16Z")

</div>

> [@atravers](#):
>
> …this is the first time I’ve seen that option mentioned here (on Discourse).

It’s also not mentioned on [https://hackage.haskell.org/](https://hackage.haskell.org/) or [Taking over a package - HaskellWiki](https://wiki.haskell.org/Taking_over_a_package). There _is_ a mention at [Hackage trustees - HaskellWiki](https://wiki.haskell.org/Hackage_trustees), but it requires a leap of analysis to realize that _requesting_ a NMU is an option for any old Haskeller.

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [March 28, 2024, 8:53am UTC](https://discourse.haskell.org/t/abandoned-haskell-packages/9168/20 "2024-03-28T08:53:20Z")

</div>

I’m concerned about this problem. It’s a difficult one because there are lots of factors in play. I don’t know what the solution should be, but here is an assorted collection of my thoughts.

### Importance

I believe that keeping things building when the ecosystem changes (new GHC/`base` releases, dependency releases) is the highest-impact ongoing maintenance task that community members can perform. It costs so, so much time and aggravation when you receive build errors when bumping a dependency bound or GHC version. Unfortunately it’s often thankless work (if people don’t see things break they don’t know that you’ve done anything) and uninteresting work.

### How to make life easier

I endeavour to swiftly respond to keep my own packages building with the latest version of GHC and dependencies. The Hackage feature that notifies you when a new major version of a dependency is released is very useful for this purpose. You can turn it on through the [account management page](https://hackage.haskell.org/users/account-management).

### Transition policy

Even though I endeavour to respond swiftly, who knows what the future may hold? To insulate my packages’ users from risk I have instigated a transition policy for Opaleye. Specifically, there is a system of [backup maintainers](https://github.com/tomjaguarpaw/haskell-opaleye/?tab=readme-ov-file#backup-maintainers) and a specific schedule under which I pre-authorize them to take over the package should I be unresponsive. Hopefully this procedure avoids the uncertainty and delays of a Hackage takeover.

I intended to promote this style of pre-authorized transition policy amongst the community more widely, but I haven’t had time to do so.

### Volunteering to help

When I ask the maintainer of a package for a version bounds bump, or a small change to keep a package compiling, I also offer to help maintain the package. I typically say “I’m willing to help maintain the package for the purpose of keeping it compiling” to reassure the maintainer that I don’t want to change or add and functionality of the package, just do basic housekeeping. Consequently, 15 of my 21 [Hackage packages](https://hackage.haskell.org/user/tomjaguarpaw) are other people’s packages that I am just volunteering to keep building. I’m not doing any development on them.

### `base` breakage

The fact that GHC releases are tied to `base` major version bumps is a big part of the problem. It means that someone has to do the busywork of bumping `base` version bounds every time GHC is released, even if the new `base` version didn’t break the compile.

### Hackage Trustees

When all that is required is to make a Hackage revision I have had a good experience [asking the Hackage Trustees](https://github.com/haskell-infra/hackage-trustees/issues) to make it (after receiving no response from the package maintainer).

[Next page](https://discourse.haskell.org/t/abandoned-haskell-packages/9168.md?page=2)