<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 15, 2017, 6:23 PM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div class="m_-1926189838223462002WordSection1">
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:36.0pt">
Therefore bytestring, process, containers, transformers, and many more will be pinned in a Stackage snapshot.<u></u><u></u></p>
</div></div><div lang="EN-GB" link="blue" vlink="purple"><div class="m_-1926189838223462002WordSection1"><p class="MsoNormal"><span style="font-size:12.0pt">So that would make it significantly harder, even impossible, for GHC releases to make any promises about the .cabal-file format of these packages, wouldn’t it?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">So even if we made some back-compat promise for non-reinstallable things like integer-gmp or base, we could not do so for bytestring.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Does that give you cause for concern? After all, it’s where Trac #14558 started. I don’t see how we can avoid the original problem, since we don’t have control over the .cabal file format used by the authors
of the packages on which we depend.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Still: GHC can only depend on a package P if the version X of Cabal that GHC is using can parse P.cabal. So if we fix Cabal-X some while in advance and announce that, perhaps that would serve the purpose?
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Simon<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><u></u> </span></p></div></div></blockquote></div><div>That will certainly help. Even if GHC can't force any behavior on upstream packages, perhaps just an official request that new features in the cabal file format be held off on would be sufficient. After all, the case in the Trac issue was a situation where the new cabal feature want necessary. I would imagine that in the vast majority of cases, maintaining backwards compatibility in these packages will not only be desirable, but relatively trivial.</div><div><br></div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div class="m_-1926189838223462002WordSection1"><p class="MsoNormal"><span style="font-size:12.0pt"><u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Michael Snoyman [mailto:<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>]
<br>
<b>Sent:</b> 15 December 2017 09:27</span></p></div></div></div></div></div><div lang="EN-GB" link="blue" vlink="purple"><div class="m_-1926189838223462002WordSection1"><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><span lang="EN-US"><br>
<b>To:</b> Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
</span></p></div></div></div></div></div><div lang="EN-GB" link="blue" vlink="purple"><div class="m_-1926189838223462002WordSection1"><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><span lang="EN-US"><b>Cc:</b> Boespflug, Mathieu <<a href="mailto:m@tweag.io" target="_blank">m@tweag.io</a>>; Ben Gamari <<a href="mailto:ben@well-typed.com" target="_blank">ben@well-typed.com</a>>; ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>></span></p></div></div></div></div></div><div lang="EN-GB" link="blue" vlink="purple"><div class="m_-1926189838223462002WordSection1"><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><span lang="EN-US"><br>
<b>Subject:</b> Re: Fwd: Release policies<u></u><u></u></span></p></div></div></div></div></div><div lang="EN-GB" link="blue" vlink="purple"><div class="m_-1926189838223462002WordSection1"><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><span lang="EN-US"></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Fri, Dec 15, 2017 at 12:10 PM, Simon Peyton Jones via ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>> wrote:<u></u><u></u></p></div></div></div></div></div></div><div lang="EN-GB" link="blue" vlink="purple"><div class="m_-1926189838223462002WordSection1"><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div><div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
| at this point in time Stackage works<br>
| hard to ensure that in any given package set, there is *exactly one*<br>
| version of any package. That's why Stackage aligns versions of core<br>
| packages to whatever ships with the GHC version the package set is<br>
| based on.<br>
<br>
Ah. It follows that if Stackage wants to find a set of packages compatible with GHC-X, then it must pick precisely the version of bytestring that GHC-X depends on. (I'm assuming here that GHC-X fixes a particular version, even though bytestring is reinstallable?
Certainly, a /distribution/ of GHC-X will do so.)<br>
<br>
If meanwhile the bytestring author has decided to use a newer version of .cabal file syntax, then GHC-X is stuck with that. Or would have to go back to an earlier version of bytestring, for which there might be material disadvantages.<br>
<br>
That would make it hard to GHC to guarantee to downstream tools that it doesn't depend on any packages whose .cabal files use new syntax; which is where this thread started.<br>
<br>
Hmm. I wonder if I have understood this correctly. Perhaps Michael would like to comment?<br>
<br>
<u></u><u></u></p>
</blockquote>
</div></div></div></div></div></div><div lang="EN-GB" link="blue" vlink="purple"><div class="m_-1926189838223462002WordSection1"><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Stackage does in fact pin snapshots down to precisely one version of each package. And in the case of non-reinstallable packages, it ensures that those package's transitive dependency set are pinned to the same version that ships with GHC. I know there's work
around making more package reinstallable, and the ghc package itself may have crossed that line now, but for the moment Stackage assumes that the ghc package and all its dependencies are non-reinstallable. Therefore bytestring, process, containers, transformers,
and many more will be pinned in a Stackage snapshot.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Michael<u></u><u></u></p>
</div>
</div></div></div></div></blockquote></div>