-
Notifications
You must be signed in to change notification settings - Fork 28
Add cabal.config link to snapshot pages #232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
See also #171 (comment) |
Any news? |
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. |
|
I don't see how that addresses the concerns I've raised. |
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. |
I don't really see a problem with the revisions because
In the improbable case that incorrect revisions break things, an user can fall back on the In light of this, here's my suggestion for the cabal guide:
|
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:
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. |
I've added a warning about the lack of support for revisions in cabal.config in f9632d7. Closing. |
For reference to anyone googling this, cabal.config files can be found at an address like (I hope this continues to be published, I find it very useful.) |
so, from Googling around, this 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 -- 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 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 |
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.The text was updated successfully, but these errors were encountered: