Make stackage sandbox put constraints in the sandbox config file

[DanBurton]

• download a fresh cabal.config
• parse and dump constraints onto the end of cabal.sandbox.config

e.g.

constraint: yesod-websockets ==0.2.1.1
constraint: zeromq4-haskell ==0.6.2
constraint: zip-archive ==0.2.3.5
constraint: zlib ==0.5.4.2
constraint: zlib-bindings ==0.1.1.5
constraint: zlib-enum ==0.2.3.1
constraint: zlib-lens ==0.1

[DanBurton]

After doing all the work of parsing/generating constraints, I discovered that this appears to be unnecessary. Perhaps this is a difference between cabal 1.18 and cabal 1.20? I'm not sure. But cat cabal.config >> cabal.sandbox.config works exactly as expected (using both cabal 1.20.0.3 and 1.22.3.0), so essentially that's what I ended up writing. (I swear I tried this a while ago and it didn't work.) I commented out and kept the other stuff I wrote in case it is useful.

I added some logic to stk sandbox init so that it won't keep any cabal.config if it didn't exist prior to the command. Therefore, stk sandbox upgrade will ultimately delete any cabal.config it finds. We may want to revisit this behavior.

I'm going to take a little more time to test this change to stackage-sandbox before releasing it.

[snoyberg]

What's the advantage of this versus using the cabal.config file?

[DanBurton]

If the user modifies the cabal.config file (for example, by doing a git pull when it is checked in to git) then when they perform installs in that directory, their shared LTS sandbox is at risk of installing the wrong versions of things. By copying the constraints into the cabal.sandbox.config, the sandbox is more likely to be protected.

[DanBurton]

With some tweaks to stackage-sandbox, this will also allow the user to write and manage their own custom cabal.config (e.g. via cabal freeze). As long as the constraints agree, there's no problem.

It may be difficult for the user to discover what the problem is when these constraints don't agree, since cabal is bad at reporting where constraints come from during a conflict. Cabal calls sandbox and cabal.config constraints "global", even though "sandbox" and "project" would be more appropriate labels.

[DanBurton]

I'm satisfied with the changes, so I've published them along with the stubbed library.