{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiciuql65xncwu3xuz7lu3psxeiezdtmficpusmy4gozx75atl4sai",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3minlnfrluie2"
  },
  "path": "/t/suggestion-deprecate-the-global-default-package-environment-file/13885#post_4",
  "publishedAt": "2026-04-04T05:11:48.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "[RFC] Revive cabal sandboxes (UX) · Issue #10098 · haskell/cabal · GitHub",
    "Separate `cabal install --lib` into own command (cabal env) · Issue #6481 · haskell/cabal · GitHub",
    "[UX] Current mechanism to install several libraries and expose them to the user? · Issue #9581 · haskell/cabal · GitHub"
  ],
  "textContent": "jaror:\n\n> So I’d rather see further limitations of that instead of changing `ghc`’s behavior. For example we could say `--lib` is only allowed if you also provide `--package-env`. You could still say `--package-env=default`\n\nWell, that would also be a breaking change.\n\nRelated issues:\n\n  * [RFC] Revive cabal sandboxes (UX) · Issue #10098 · haskell/cabal · GitHub\n  * Separate `cabal install --lib` into own command (cabal env) · Issue #6481 · haskell/cabal · GitHub\n  * [UX] Current mechanism to install several libraries and expose them to the user? · Issue #9581 · haskell/cabal · GitHub\n\n\n\nI personally think for something like `cabal install --lib`, which is by nature an _imperative_ command, the default should indeed be to install globally. That’s what 98% of the package managers do and what users are generally used to.\n\nThe problem is that cabal’s UX is now a hot mess, with some semi-declarative interface that doesn’t actually go all the way. And now people mix both of those paradigms and cabal isn’t very good at separating those. This is what sandboxes were good at: imperative, but local.",
  "title": "Suggestion: deprecate the global default package environment file"
}