# Can backpack solve the 'basement' problem?

**URL:** <https://discourse.haskell.org/t/can-backpack-solve-the-basement-problem/13749>\
**Category:** Learn\
**Created:** [February 27, 2026, 2:55pm UTC](https://discourse.haskell.org/t/can-backpack-solve-the-basement-problem/13749 "2026-02-27T14:55:23Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![mihaimaruseac](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mihaimaruseac/32/5460_2.png) [@mihaimaruseac](https://discourse.haskell.org/u/mihaimaruseac)\
**Post date:** [February 27, 2026, 2:55pm UTC](https://discourse.haskell.org/t/can-backpack-solve-the-basement-problem/13749/1 "2026-02-27T14:55:23Z")

</div>

> [@Fork \`basement\`? As \`baseplate\`?](https://discourse.haskell.org/t/fork-basement-as-baseplate/12415/53):
>
> I do think there are awkward questions around: suppose I depend on `a` and `b`, which both depend on `x`. `x` gets forked into `x2`, and `a` updates to use that but `b` doesn’t. I say “`x` is provided by `x2` instead”. Are types `x2:X.T` (visible to me via `a`) and `x:X.T` (visible to me via `b`) the same type? We can’t get into this situation with github right now I think, because if you point at a github repo it needs to know what name you use it as.

It was my understanding that backpack could solve this. Unfortunately, from what I know, backpack is not yet widely supported. And I might be wrong about 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:** [February 27, 2026, 7:16pm UTC](https://discourse.haskell.org/t/can-backpack-solve-the-basement-problem/13749/2 "2026-02-27T19:16:06Z")

</div>

Yeah, backpack could let you depend on an abstract interface which can be instantiated by both `x` and `x2`. Then the end-user can choose which concrete implementation to use. But then someone would have to maintain that abstract interface. Backpack is supported by GHC and Cabal, but not really by other tooling (notably Stack, ~~Hackage~~ , and HLS). I think the lack of support never made it convenient enough to gain traction and nobody wants to improve the tooling support because it is not used by anyone.

---

<div class="post-metadata">

**Author:** ![mihaimaruseac](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mihaimaruseac/32/5460_2.png) [@mihaimaruseac](https://discourse.haskell.org/u/mihaimaruseac)\
**Post date:** [February 28, 2026, 3:27pm UTC](https://discourse.haskell.org/t/can-backpack-solve-the-basement-problem/13749/3 "2026-02-28T15:27:38Z")

</div>

I think scenarios like the one(s) discussed in this topic make a point that backpack or similar progress is needed.

Wish I had more free time ☹

---

<div class="post-metadata">

**Author:** ![sclv](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/sclv/32/71_2.png) [@sclv](https://discourse.haskell.org/u/sclv)\
**Post date:** [February 28, 2026, 7:22pm UTC](https://discourse.haskell.org/t/can-backpack-solve-the-basement-problem/13749/4 "2026-02-28T19:22:17Z")

</div>

Backpack is supported by hackage (eg [lsp-types: Haskell library for the Microsoft Language Server Protocol, data types](https://hackage.haskell.org/package/lsp-types))

Although further UI work has been discussed and is welcome (eg [UI for multiple public libraries · Issue #1218 · haskell/hackage-server · GitHub](https://github.com/haskell/hackage-server/issues/1218))

---

<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:** [February 28, 2026, 9:04pm UTC](https://discourse.haskell.org/t/can-backpack-solve-the-basement-problem/13749/5 "2026-02-28T21:04:33Z")

</div>

> [@sclv](#):
>
> Backpack is supported by hackage (eg [lsp-types: Haskell library for the Microsoft Language Server Protocol, data types](https://hackage.haskell.org/package/lsp-types))

I don’t see any backpack in lsp-types, only multiple public sublibraries. It does seem like it has some support for backpack, for example it does list the [`Key`](https://hackage.haskell.org/package/unpacked-containers-0/docs/Key.html) signature for the [`unpacked-containers`](https://hackage.haskell.org/package/unpacked-containers) package. However, it seems to choke on [`raaz`](https://hackage.haskell.org/package/raaz) (perhaps that is also related to the issue you linked?).

---

<div class="post-metadata">

**Author:** ![sclv](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/sclv/32/71_2.png) [@sclv](https://discourse.haskell.org/u/sclv)\
**Post date:** [February 28, 2026, 11:17pm UTC](https://discourse.haskell.org/t/can-backpack-solve-the-basement-problem/13749/6 "2026-02-28T23:17:08Z")

</div>

Fair points. When you say it chokes on raaz, what do you mean? Do you mean that it does not display the modules it should? (I think it does). Or do you mean that not all the modules have documentation? If the latter, this may be a haddock issue or an issue with how cabal invokes haddock (cf: [Backpack and multiple public library interop · Issue #1363 · haskell/haddock](https://github.com/haskell/haddock/issues/1363))

In either case, I do think more work and patches are welcome. As is however, certainly packages using backpack can be posted to hackage, at least somewhat browsed, and then in turn used by cabal. While ergonomics and UI can be improved, I do not think this is a barrier to adoption.

---

<div class="post-metadata">

**Author:** ![danidiaz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/danidiaz/32/92_2.png) [@danidiaz](https://discourse.haskell.org/u/danidiaz)\
**Post date:** [March 1, 2026, 9:16am UTC](https://discourse.haskell.org/t/can-backpack-solve-the-basement-problem/13749/7 "2026-03-01T09:16:04Z")

</div>

I don’t think Backpack, by itself, would be a solution for the “basement” problem.

All the libraries that used “basement” would have to remain “indefinite” in the Backpack sense and depend on a signature instead. We would only commit to an implementation in executables (and test suites).

So we’re back to a big coordination problem. And it would be difficult for participants to agree from the beginning because, when starting to depend on a library like “basement”, one doesn’t expect for it to become unmaintained!

I believe Backpack makes more sense when multiple instantiations of some library are planned from the beginning. But in the “basement” case, we need something like a way to “override” packages while the dependencies slowly adapt across the ecosystem.

---

<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 1, 2026, 9:57am UTC](https://discourse.haskell.org/t/can-backpack-solve-the-basement-problem/13749/8 "2026-03-01T09:57:39Z")

</div>

Perhaps we should normalize everybody specifying interfaces for all their dependencies. Even if you only ever want to use one specific implementation, it is still good for maintainability to specify what specific parts of your dependencies you are using and how that forms a cohesive interface. Making your interfaces explicit is the first step to keeping them small, increasing cohesion and reducing coupling.

The main problem I can think of is the extra maintenance burden of maintaining these interfaces. If HLS had a code action to add things to a backpack signature just like it has one for adding an import or making all imports explicit, then perhaps this would be more feasible.

---

<div class="post-metadata">

**Author:** ![danidiaz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/danidiaz/32/92_2.png) [@danidiaz](https://discourse.haskell.org/u/danidiaz)\
**Post date:** [March 1, 2026, 2:16pm UTC](https://discourse.haskell.org/t/can-backpack-solve-the-basement-problem/13749/9 "2026-03-01T14:16:19Z")

</div>

> [@jaror](#):
>
> Perhaps we should normalize everybody specifying interfaces for all their dependencies.

That would be an interesting experiment. I suspect it could even help with LLM-based coding because, on one hand, a signature is the natural place to document how you intend to use some library and, on the other, it would help the LLM to find relevant context without jumping around too much. I think [this](https://www.youtube.com/watch?v=uC44zFz7JSM) (not Haskell related) video is relevant.

One problem with it is that we would lose the information provided by dependency version bounds. But perhaps we can always provide a properly instantiated version of the code in a separate public library.