{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreif7aqfg26wwnh6likd7pzslet7jxt4ewr3lrdbau535qbkmt3kk4y",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mfykdmhjj272"
  },
  "path": "/t/can-backpack-solve-the-basement-problem/13749#post_7",
  "publishedAt": "2026-03-01T09:16:04.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "I don’t think Backpack, by itself, would be a solution for the “basement” problem.\n\nAll 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).\n\nSo 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!\n\nI 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.",
  "title": "Can backpack solve the 'basement' problem?"
}