On Wed, Sep 3, 2014 at 10:52 AM, Peter <voldermort@hotmail.com> wrote:
Michael Snoyman <michael <at> snoyman.com> writes:

> The preparing your system for Stackage page[1] has those auto-updated
links available (e.g., GHC 7.8 exclusive is [2]).

Thank you. I read the page at least 3 times, but missed that because the
links redirected to the latest snapshot, and the Stackage server only has
static snapshot links. Perhaps it should be made clearer that these links
will redirect to the current snapshot, and add them to
http://www.stackage.org/snapshots as well?


That would be a good idea if I wanted people to directly use those URLs, which I think is generally a bad idea. The lack of explicitness about the presence of a redirect there is a feature, not a bug ;).
 
> You already identified the downside with this: you may magically be
upgraded to a new version of a package. If you really want to do this, you
can, but my recommendation is to manually decide to upgrade your Stackage
snapshot consciously instead of letter an arbitrary Jenkins build server
make the decision for you.

I'm using Stackage as a QA'd Hackage. It sounds like you see it more as a
server-side cabal freeze.


I'm not sure what distinction you're going for in this. Imagine the following sequence of events:

* You set up your system to use Stackage, with September 1's snapshot being active at the time.
* You install foo-1.1, with bar-1.1 depending on it.
* A new Stackage snapshot comes out, providing foo-1.2.
* You now try to install something depending on foo, and depending on the alignment of the stars, cabal will either download a new foo or use the already installed one.

In other words, the usage you seem to be implying is highly non-deterministic, which I'd be very careful about using.

Michael