There was tremendous response to our Stackage survey, so I’d like to say: thank you everyone who participated, the feedback was invaluable. Additionally, in the past two weeks, I think we’ve added around 100 new packages to Stackage based on everyone’s pull requests, so again, thank you for everyone who got involved. You can view the survey results yourself (no longer available). Of particular interest to me were the freeform responses, which gave us a lot of valuable information.
Chris Done and I went over the results together, and by far, the strongest impression that we got was that the Stackage setup process was too onerous. Lack of direct cabal-install support and need to choose from among six possible snapshots were very problematic. Furthermore, some people found the homepage confusing, and didn’t understand from it why they should use Stackage. There was also fear that, by using Stackage, you’d end up missing out on some important packages, either because those packages aren’t present, or because it’s unclear how to add new packages.
So today, we’re announcing a number of changes on stackage.org to address these concerns, as well as to pave the way for the upcoming LTS Haskell release. These changes are still a work in process, so please give us feedback (or feel free to send a pull request as well).
In order to use Stackage, you first had to choose GHC 7.8, GHC 7.8 + Haskell Platform, or GHC 7.6. You then had to decide if you wanted exclusive vs inclusive. Once we add LTS Haskell, that’s another choice to add to the mix. So we’ve decided to simplify the options advertised on the homepage to two:
Each of these will be compatible with only one version of GHC (7.8.3 for now). Another piece of feedback is that users are by far using inclusive more commonly than exclusive. So we’re going to default to giving inclusive instructions.
One important thing to keep in mind is that this will not affect current users at all. All snapshots currently hosted on stackage.org will remain there in perpetuity. We’re talking about discovery for new users here.
Until now, we’ve recommended setting up Stackage by changing
your remote-repo setting to point to the appropriate
stackage.org URL. In October, Greg Weber came
up with the idea of generating a cabal.config file
to specify constraints instead of using a manual URL. We’ve
decided
to make this the preferred Stackage setup method. This provides
a number of benefits for you immediately:
The downsides with this are:
cabal.config file
contains an optional remote-repo line which you can
uncomment to get back exclusive-style snapshots.hackage.fpcomplete.com as an alternative
remote-repo, hosted by Amazon S3.As a result of this change, getting set up with Stackage is now
as easy as downloading a
cabal.config file, placing it in your project
directory, and running cabal install. Our homepage has
easy to use instructions for this as well.
Speaking of the homepage: we’ve updated it to:
Relevant Github issue with more details
The snapshot pages now list all packages in the snapshot, together with version numbers, synopses, and documentation links (if available). The setup instructions are also much simpler on each snapshot page.
We’ve also set up nicer URLs for the commonly used snapshots. In particular:
/nightly will take you to the latest nightly/nightly/2014-12-15 will take you to the December
15, 2014 nightly/lts will take you to the latest LTS/lts/1 will take you to the latest LTS in the 1
series/lts/1.3 will take you to LTS 1.3Relevant Github issue with more details
We’ve streamlined the package pages to provide the most pertinent information. Have a look for yourself. Of particular interest, we now have inline links for Haddock documentation. You can now very easily start browsing docs from just looking at a package page.
Relevant Github issue with more details
There’s now a dedicated installation instructions page targeted at people without a Haskell installation. This page is controlled by a Markdown file on Github, and pull requests to improve content are very much welcome!
I’ve created the LTS Haskell repo. I’m populating it with 0.X releases now as pre-release testing. To reiterate: LTS Haskell is not launched yet, and I will be holding off on an official 1.0 until January 1. So if you have packages you want in LTS, you still have two weeks to get them in.
I’ve also done a major overhaul of the Stackage codebase itself to make for far more reliable builds. There are lots of details involved, but they’re probably not too terribly interesting to most readers. The important takeaways are:
This decision is still up for discussion, but my plan is to discontinue Stackage daily builds for GHC 7.6 and GHC 7.8 + Haskell Platform. The reasons are:
If you’re using a Haskell Platform installed toolchain now, I recommend trying out the new installation instructions to get a toolchain that will be fully compatible with both LTS Haskell and Stackage Nightly.
One future policy decision we’ll need to make is: when do we upgrade to a new version of GHC. My proposed plan is that, once we get a successful nightly build with a new GHC version, we stop generating nightlies for the old version. For LTS Haskell, we’ll use whatever version of GHC is used by the nightlies at the time we take a snapshot.
The upshot of this will be that, at any given time, there will be at most two supported GHC versions by the official Stackage snapshots: whatever nightly supports, and the version used by LTS, which may be one version behind.
Subscribe to our blog via email
Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.