"Stable Hackage": vetted consistent packages from Hackage (by commercialhaskell)


Basic stackage repo stats
5 days ago

commercialhaskell/stackage is an open source project licensed under MIT License which is an OSI approved license.

Stackage Alternatives

Similar projects and alternatives to stackage

  • GitHub repo hackage-trustees

    Issue tracker for Hackage maintainance and trustee operations

  • GitHub repo tilapia

    Improving all Haskell's programmer interfaces

  • GitHub repo haskell-book-exercises

  • GitHub repo ring

    Safe, fast, small crypto using Rust (by briansmith)

  • GitHub repo cargo-crev

    A cryptographically verifiable code review system for the cargo (Rust) package manager.

  • GitHub repo purescript-halogen

    A declarative, type-safe UI library for PureScript.

  • GitHub repo ghc-proposals

    Proposed compiler and language changes for GHC and GHC/Haskell

  • GitHub repo hpack

    hpack: A modern format for Haskell packages

  • GitHub repo AreWeRustYet

    Awesome list of "Are We *thing* Yet" for Rust

  • GitHub repo cargo-supply-chain

    Gather author, contributor and publisher data on crates in your dependency graph.

  • GitHub repo typelevel-rewrite-rules

    rewrite rules for type-level equalities

  • GitHub repo uuid

    A Haskell library for creating, printing and parsing UUIDs (by haskell-hvr)

  • GitHub repo

    blog frontend

  • GitHub repo ghc-proposals

    Proposed compiler and language changes for GHC and GHC/Haskell (by Kleidukos)

NOTE: The number of mentions on this list indicates mentions on common posts. Hence, a higher number means a better stackage alternative or higher similarity.


Posts where stackage has been mentioned. We have used some of these posts to build our list of alternatives and similar projects - the last one was on 2021-04-03.
  • [GHC Proposals] GHC Maintainer preview | 2021-04-03
    On the contrary, I think this is standard practice for packages which are part of stackage. When stackage nightly switches to a new version of ghc, all the packages which are incompatible with the new ghc are dropped from nightly. My understanding is that maintainers are then expected to fix their packages, at which point more and more packages are included in the nightly snapshot. The next lts to include that version of ghc is only released later, once most packages have been added back, so unlike ghc users who diligently upgrade to the latest ghc, stackage users who diligently upgrade the latest lts snapshot shouldn't see a big drop in the number of compatible packages.
  • Setup dev container with language server out of the box
    I found the latest stack lts version, and it's associated ghc version here:
  • Maybe We Can Have Nice Things | 2021-02-18
    This is a common misconception, the packages in Stackage are only required to build together and pass their own test suite (if present, and this is also not a hard requirement), and also anyone can add packages. Quality assurance/selecting "blessed" packages is not part of the design of Stackage.
  • Haskell as a first timer - Am I missing something ? | 2021-02-03
    I will say that perhaps upper-bounds shouldn't (or rarely) exist? Smarter people than me have probably discussed it to death. But upper-bounds aside, different packages working together is a property of those packages, not of whatever tool happens to build them, so package inconsistency or "cabal hell" should naturally arise from any tool that actually checks if two packages have declared themselves as mutually incompatible...
  • Talk about new random's interface | 2021-01-28
    That's the perfect place for this question. The answer is a lot of packages depend on random and a lot of people put restrictive upper bounds, because that's what PVP advises us to do. So, it is expected for a community to take some time to catch up. Here is the ticket that lists the list of the packages that are left to be updated: