commercialhaskell

stackage

Dockerfile2013–2019

commercialhaskell / stackage

stackage

Stable Haskell package sets: vetted consistent packages from Hackage

Explore on GitHub Read Hacker News discussions

6Distinct people

6Mentions

0Explicit recommenders

550GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Stable Haskell package sets: vetted consistent packages from Hackage

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year6 dated mentions

Observed mentions: 2013-03-11 16:04:56 UTC to 2019-08-05 21:59:47 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2013	2013-01-01 00:00:00 UTC	2014-01-01 00:00:00 UTC	1	0	1
2014	2014-01-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	1	0	1
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	1	0	1
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	0	0	0
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	2	1	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	0	1

What Hacker News says

6 sources

ben509·Aug 5, 2019

> You'd need to pin all transitive dependencies as well and cache the venv. I think to do this stuff, you need hooks in Jupyter to setup and teardown the venv before it runs the kernel. (And generally Jupyter would want to clean up unused venvs to mitigate the teardown hook not firing.) > Only issue is that it'd be really space inefficient A venv is overkill. You can just run the kernel in a regular directory, and `pip install --target kernel_dir foo-bar-pkg` to put packages directly in it. As long as the linker sees it, third-party libraries will work. This technique is used in the serverless project[1] to bundle dependencies for use on AWS Lambda. > Not sure if you'd need to find older versions of new direct dependencies to avoid conflicts. Curation is a solution to this. Stackage[1] is popular in the Haskell community; they build a con

Read the rest

sistent version set of everything every night and curate stable releases periodically. With curation, a date and a set of top-level packages is enough to pin your dependencies. [1]: https://github.com/commercialhaskell/stackage#frequently-ask... [2]: https://github.com/UnitedIncome/serverless-python-requiremen...

In Show HN: FunctorFlow – An attempt to re-imagine Python libraries

amatheus·Dec 26, 2017Submission

the http-types library broke 26 packages to fix a typo in a joke

1 points · Open discussion

tazjin·Mar 3, 2017

I am a "domain expert" and that is why I use stack for Haskell projects. It's much preferable to let somebody else handle the burden of ensuring that certain dependencies are compatible with each other. > Stack is a mysterious "solution" to a problem There's nothing mysterious about stack. It's just a group of people who step up and say "I am responsible for package $x" and then work together to find stable sets of versions that are guaranteed to work together. The whole process happens out in the open, for example here is an issue tracking a compatibility breaking change in a common HTML library: https://github.com/fpco/stackage/issues/2246

In How we secretly introduced Haskell and got away with it

MaxGabriel·Jan 4, 2015

There are a couple questions in the comments about LTS Haskell and related projects, I was thinking this might be a good summary. (tel's might be better, but I had already written this so I'll let others decide https://news.ycombinator.com/item?id=8834823) Hackage is the core package server, comparable to RubyGems. The Stackage (http://www.stackage.org/) project functions like a CI system for Hackage. Stackage builds and tests the group of packages that have opted in to it, ensuring that the latest versions all work together (when there's an incompatibility between packages, the authors of the packages are pinged to resolve the issue [1]). When a build of all the packages succeeds, Stackage generates a "snapshot", a list of all the package versions used for that build (sort of like a Gemfile.lock/Podfile.lock, for the whole ecosystem). De

Read the rest

velopers can have Cabal (Haskell build tool) use the package versions from that list when installing new packages. This ensures that when you install a new package that it's compatible with the other packages you're currently using. The issue with those snapshots (generated nightly) is that you'll want to get updates for your packages, but the snapshot generated N days from now might have packages that have made breaking API changes, making them incompatible with your application. LTS Haskell attempts to fix that. It's based off a specific Stackage snapshot. For the duration of the LTS (currently 3 months), the major versions from that snapshot are locked down, but patches/bugfixes will continue to be released. This allows you to get bugfixes for your application while still getting the advantages of Stackage. [1] As an example, when the language-ecmascript 0.17 package was released, the authors of the 2 packages that depended on language-ecmascript < 0.17 were pinged to update their packages: https://github.com/fpco/stackage/issues/390

In Announcing LTS Haskell 1.0

massysett·Mar 26, 2014

"Why Hackage packagers like to specify upper bounds I'm not sure of." There is a policy that says you're supposed to do this: http://www.haskell.org/haskellwiki/Package_versioning_policy The idea is that by specifying upper bounds, the package is more likely to build after the dependencies change. This idea is subject to considerable controversy. http://www.haskell.org/pipermail/haskell-cafe/2012-August/10... There's also been more recent mailing list traffic on it, but my Google skills are failing me here and the arguments haven't changed all that much. My opinion is that we are relying too heavily on upper bounds to solve a whole bevy of interrelated, but separate, problems. Other solutions are evolving to help deal with some of the problems. cabal sandboxes allow you to build a package separately from your others, reducing dependency

Read the rest

issues. cabal freeze will help you specify exact dependencies, including transitive ones. Another project, Stackage, aims to maintain a whole slew of packages in a buildable state: https://github.com/fpco/stackage

In What it's like to use Haskell

yogsototh·Mar 11, 2013

Concerning the cabal dependencies problem. I didn't tested it yet, but I believe a sane solution should be to use stackage[1]. I know fpcomplete use stackage for their School of Haskell[2]. This way, there is never any package dependency problem. Which gives them the incredible ability to execute yesod application directly on their server from the code of an user changing the code in the browser. If you haven't did it yet, you should really try it. Also, concerning the deployment, having a single statically linked binary is very similar to having a single jar file. And this is very easy to deploy using heroku for example. You can ask me more detail if you want to know how I deploy my application but this is mostly very well documented in the wiki. [1]: https://github.com/fpco/stackage [2]: https://www.fpcomplete.com/school

In Why Lift is My Favorite Web Framework