Use cabal.config with constraints as primary means of using Stackage

[snoyberg]

Reasoning:

1. Backwards compatible with older versions of cabal-install
2. Plays well with the move for more emphasis on inclusive. In particular: no need to worry about newly released packages not being included
3. Makes it trivial for people to tweak the package set if desired
4. More transparent
5. Can still provide the remote-repo approach, which will automatically function as the exclusive version of a snapshot

Downsides:

1. Relies on Hackage being reliable (though we can always point people to our more reliable mirror at hackage.fpcomplete.com)
2. Makes for a large cabal.config file

Should do:

• Add a comment to the top of cabal.config indicating the official snapshot URL

@chrisdone What do you think of this transition?

[mboes]

In principle this sounds good to me. But, potential annoyances:

• cabal configure ignores cabal.config constraints haskell/cabal#2143
• cabal doesn't reconfigure after cabal.config changes. haskell/cabal#1992

[snoyberg]

Sigh. Story of my life, a nice idea trampled on by cabal bugs :(

[snoyberg]

Well, haskell/cabal#1992 isn't any worse than using the remote-repo trick. With remote-repo, you're required to wipe out your old package database to ensure no old packages linger. Seems like the same applies with that cabal bug, with the improvement that- when the bug is fixed- you won't need to wipe out your database. So I don't think that should be a blocker, but I'm not sure yet.

Actually, seems like the same argument applies to the other bug as well. So I'm thinking we can move ahead with this anyway. Am I mis-analyzing?

[chrisdone]

The pro- points make sense. Another advantage is:

1. Already has a straight-forward and automatic process for committing to source control.

I don't quite understand the bug. What's the point in cabal.config if cabal configure doesn't read it? Is there a work around? cabal clean?

[snoyberg]

It looks to me like the constraints are being used when choosing dependencies to install, but are being ignored when selecting which set of installed dependencies should be used.

[mboes]

With remote-repo, you're required to wipe out your old package database to ensure no old packages linger.

Hm, so that alone is a big argument in my mind in favour of cabal.config.

I don't think that the two bugs I uncovered are blockers, just potential annoyances that we need to be aware of. The good news is that while it's arguably the case that cabal freeze is currently afflicted with quite a bit of odd behaviour (search for "freeze" in cabal issues), most of them shouldn't affect us because Stackage is effectively prescribing the content of cabal.config - we don't need help from cabal-install to author it.

@mietek has a lot of experience using cabal freeze as part of his Halcyon project. What do you think?

[snoyberg]

Funny you should mention Halcyon, I was just looking at that a few hours
ago.

It sounds like we're in agreement then on how our next iteration of
installation instructions will look, we'll just need to document corner
cases well.

On Wed, Dec 10, 2014, 2:41 PM Mathieu Boespflug [email protected]
wrote:

With remote-repo, you're required to wipe out your old package database to
ensure no old packages linger.

Hm, so that alone is a big argument in my mind in favour of cabal.config.

I don't think that the two bugs I uncovered are blockers, just potential
annoyances that we need to be aware of. The good news is that while it's
arguably the case that cabal freeze is currently afflicted with quite a
bit of odd behaviour (search for "freeze" in cabal issues), most of them
shouldn't affect us because Stackage is effectively prescribing the content
of cabal.config - we don't need help from cabal-install to author it.

@mietek https://github.com/mietek has a lot of experience using cabal
freeze as part of his Halcyon project. What do you think?

—
Reply to this email directly or view it on GitHub
#51 (comment).

[mietek]

Halcyon already includes a workaround for haskell/cabal#2143 and haskell/cabal#1992, and many other Cabal bugs.

I am also working on improving the dependency upgrade workflow. Remember the --ignore-frozen and --ignore-all-frozen flags proposed in haskell/cabal#1519 (comment)?

[mietek]

Please take a look at haskell/cabal#2265.

[benarmston]

Another issue with cabal freeze that is likely relevant is haskell/cabal#1745 and the related pull request haskell/cabal#1755.

@mboes I think you are right about cabal freeze having some odd behaviour. In part due to my lack of understanding of some subtleties in cabal's resolver's behaviour and the various ways in which it can be invoked. But also due to a lack of agreement on precisely how it should work and exactly what use cases it should be supporting.

Which can only really be changed with issues about what use cases it is currently failing to support. So if you come across any odd behaviour which doesn't already have a ticket, please create one. I don't have that much time to work on fixing the issues, but I do intend to get to them eventually.

[snoyberg]

This discussion has been good. AFAICT, there's no strong argument right now to avoid using the cabal.config approach, though we should keep an eye out on various cabal issues. I'm going to close this issue as resolved, but if someone thinks there's something else to be addressed, please reopen.