Add cabal.config link to snapshot pages

[fgaz]

As the title says, I propose to restore the link to the cabal.config file in the snapshot pages.
It doesn't take much space (you can even hide it under a "+", just tell me if you want a pr for it), and it's one of the two ways to use Stackage (more so, it's the original one!).

I'm sure it will be useful to many. I only knew about that file because I already used it when the link was there, but probably a lot of people don't realize it's even available (it's an orphan page).

All it takes is a git revert e0f8755.

[hvr]

See also #171 (comment)

[fgaz]

Any news?

[snoyberg]

Just chatted with Chris about this. We removed the link originally because it was causing user confusion with uncertainty on how to get started with Stackage. As users standardized on the Stack+Stackage workflow, it made sense to avoid the confusion.

I'm not opposed to adding in information on using with cabal-install again, but in its current state, I don't believe we can advertise the cabal.config file. In particular, due to Hackage file revisions sometimes breaking old build plans, the current format (which does not include any Hackage file revision information) is unsuitable. I'm not familiar with all the details of cabal.config files to know if they support indicating Hackage file revisions. Such a change would be necessary to reliably provide support for cabal-install.

[fgaz]

--index-state can do it. Just make the instructions like this:

curl https://www.stackage.org/$snapshot/cabal.config > cabal.project.freeze
cabal whatever --index-state=$snapshot_date

[snoyberg]

I don't see how that addresses the concerns I've raised.

[DanBurton]

cabal has gained a feature called --index-state which allows you to interact with the entire package index as though it were $snapshot_date (meaning: without any new versions or revisions that occur after that date). So as long as the cabal.config that we publish works on $snapshot_date, we just also publish the date, and users can use this technique to guarantee consistent builds, even despite changes to the package index on later dates.

I'm not convinced that this is a good workflow, though. If users want to add any packages outside of the snapshot, it will be confusing to them why outside packages are also arbitrarily constrained to old versions.

[fgaz]

I don't really see a problem with the revisions because

1. They are designed to not break anything when used correctly (which is fairly easy to do).
2. Anedoctally, they do not break things in 99% of cases.
3. If you are entrusting your deps' developers with running code on your sistem you should trust them to mantain correct revisions too.

In the improbable case that incorrect revisions break things, an user can fall back on the --index-state method until they are corrected (or permanently).

In light of this, here's my suggestion for the cabal guide:

[+ cabal-install guide]
↑ when clicked will expand the section

[BIG SCARY RED WARNING ABOUT HOW THIS METHOD IS NOT SUPPORTED BY FPCOMPLETE]

curl https://www.stackage.org/$snapshot/cabal.config > cabal.project.freeze
cabal whatever
This should work in most of cases. If it fails with a [check what error it is], there is a chance that the error is caused by incorrect revisions.
In this case, you can try:
cabal whatever --index-state=$snapshot_date
If the problem is fixed by the --index-state flag [link to what it does], you should report the revision problem to the author of the offending package.
You can also use --index-state to ensure that your install plan will never change.
N.B.: --index-state will also constrain all your other dependencies to versions before the date blah blah blah...

[snoyberg]

The fact is that Hackage revisions have broken snapshots in the past, this isn't a theoretical discussion. And the point of Stackage is to give guarantees about build plans, which currently can only be done through Stack (unless someone wants to PR the cabal.config files we generate to include the Hackage file revision info).

To reiterate: there are two different issues here:

• Confusing users about how to get started. We're recommending they get started with Stack, because it works reliably. We are not recommending they use cabal, since it does not have first class support for Stackage, or even correct support in the presence of Hackage revisions
• If we include this information and people have a negative experience, it will reflect badly on Stackage and/or cause maintenance overhead for the Stackage Curator team

If you are entrusting your deps' developers with running code on your sistem you should trust them to mantain correct revisions too.

The issue is that maintaining revisions that don't break a snapshot is a tricky job, and people make mistakes. Additionally, it's not just the developers themselves; Hackage Trustees can add overly restrictive bounds that break snapshots too.

[snoyberg]

I've added a warning about the lack of support for revisions in cabal.config in f9632d7. Closing.

[bsima]

For reference to anyone googling this, cabal.config files can be found at an address like https://www.stackage.org/lts-9.21/cabal.config

(I hope this continues to be published, I find it very useful.)

[sboosali]

so, from Googling around, this cabal.project stanza should:

repository stackage-lts-12.12
  url: stackage-lts-12.12:http://www.stackage.org/lts-12.12

For the latest version of the latest long-term support snapshot, I downloaded the cabal.config at [https://www.stackage.org/lts/cabal.config?global=true], which redirects you to (as of today, October 2018) lts-12.12, which includes this comment:

-- To only use tested packages, uncomment the following line
-- and comment out other remote-repo lines:
-- remote-repo: stackage-lts-12.12:http://www.stackage.org/lts-12.12

which cabal says is legacy, so I (trivially) desugared the field to a remote-package-repository stanza, as documented at [https://www.haskell.org/cabal/release/cabal-1.24.0.0/doc/users-guide/installing-packages.html#legacy-repositories].

I want to make sure this works, does anyone know how to force a particular repository to be exclusive? (i.e. hiding the default/implicit repository hackage.org rather than merging then as it does).