<div dir="ltr">I always wondered: do we need a package management system at all?<div><br></div><div>Putting aside for a second the problem of interfacing with C or other external dependencies.</div><div><br></div><div>What about a system where every source file is automatically annotated with a unique hash and all the required LANGUAGE extensions.</div><div><br></div><div><br></div><div>For example:</div><div><br></div><div>-- State explicitly any non-standard language extension</div><div><div style="color:rgb(0,0,0);font-family:Menlo,Monaco,"Courier New",monospace;font-size:12px;line-height:18px;white-space:pre"><div><span style="color:rgb(0,0,255)">{-# LANGUAGE MultiParamTypeClasses ,PatternSynonyms ,RankNTypes #-}</span></div></div></div><div><br></div><div>-- Add to the module name its hash (calculated on its source contents, ignoring comments)</div><div>module App.Main.<span style="color:rgb(0,128,0);font-family:Menlo,Monaco,"Courier New",monospace;font-size:12px;white-space:pre">K306f1981b41c</span></div><div><br></div><div>-- Import a module, specifying the exact version</div><div>import Data.Maybe.K306f1981823d</div><div><br></div><div>....</div><div><br></div><div>main: ...</div><div><br></div><div><br></div><div>Finally, we publish it on a shared content addressable system (hackage like).</div><div><br></div><div><br></div><div>This module is in fact now a stand-alone mini-package that can be easily built as it states all its dependencies in a non-ambiguous way:</div><div><br></div><div>lookMaNoPackages run App.Main.<span style="color:rgb(0,128,0);font-family:Menlo,Monaco,"Courier New",monospace;font-size:12px;white-space:pre">K306f1981b41c</span></div><div></div><div><br></div><div><br></div><div>The nice thing is that it could be done in a completely backwards-compatible way, as it doesn't require any change to the language itself.</div><div><br></div><div>And a modern tool like haskell-language-server could automate the hashing/annotations making it convenient to use.</div><div><br></div><div>Would this work? </div><div><br></div><div><br></div><div> titto</div><div><br></div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno ven 11 dic 2020 alle ore 12:40 Jack Kelly via Haskell-Cafe <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
December 11, 2020 7:50 PM, "Bardur Arantsson" <<a href="mailto:spam@scientician.net" target="_blank">spam@scientician.net</a>> wrote:<br>
<br>
> On 10/12/2020 22.07, Jack Kelly via Haskell-Cafe wrote:<br>
><br>
>> [snip]<br>
><br>
> Absolutely agreed that there is currently to "Right Answer"(TM) wrt.<br>
> Cabal or Stack. They do different things well/badly. Until we get a tool<br>
> that can do everything the schism will probably remain.<br>
> <br>
> (And that's not even talking about issues like technical debt in each of<br>
> the code bases, etc.)<br>
<br>
I'm glad my message was taken in the right way.<br>
<br>
> My problem here is that Cabal hasn't provided some very useful the<br>
> features that YAML does out of the box, namely the ability to define<br>
> arbitrary snippets of package configuration and to refer to them from<br>
> multiple places. Examples:<br>
> <br>
> If I maintain a cohesive set of 5 packages, I need to duplicate various<br>
> bits and bobs of information in 5 different places:<br>
> <br>
> [snip things that really should be DRY'd up by a modern build tool]<br>
<br>
While it does not solve the problem you have in full, common stanzas can at least help you de-duplicate ghc-options settings within a package. <a href="https://cabal.readthedocs.io/en/latest/cabal-package.html?#common-stanzas" rel="noreferrer" target="_blank">https://cabal.readthedocs.io/en/latest/cabal-package.html?#common-stanzas</a><br>
<br>
A possible solution: allow cabal.project to set common entries across multiple packages, and have `cabal sdist` write them into the cabal file that goes into the tarball? This is just me spitballing, so there are probably problems that I haven't considered.<br>
<br>
> This is tedious at best and outright wrong<br>
> at worst (inconsistent version bounds).<br>
> In no way am I advocating for YAML specifically.<br>
> (Dhall could work here since you can at least do inclusions and reuse in<br>
> a generic way. Plus it has fully defined semantics plus implementations<br>
> in at least a couple of langauges, Haskell and Scala.)<br>
<br>
I see that Oliver has already mentioned dhall-to-cabal . I'm a fan, but I'd be worried about bootstrappability if it became the main language of the main build tool.<br>
<br>
>> - Many stack projects do not provide bounds on dependencies<br>
> I posit that at least a *part* of the problem here is tedium for<br>
> maintainers (see above), but while we're at it: I'm not sure manually<br>
> maintaining bounds is at all scalable nor particularly "correct" (for<br>
> lower bounds, esp.) unless one is *super*-vigilant about what bits of a<br>
> dependency are *actually* in use.<br>
> <br>
> FWIW, I do try to do this for my packages, but I'm very confident that<br>
> all of my packages probably have misleading lower bounds.<br>
> <br>
> It seems to me that some automated tooling is needed here, e.g. to try<br>
> building/testing with e.g. all deps at the lower bound, all deps at the<br>
> highest bound, etc.<br>
<br>
No doubt. The only way to have a hope of doing this is with a CI matrix. <a href="https://github.com/haskell-CI/haskell-ci" rel="noreferrer" target="_blank">https://github.com/haskell-CI/haskell-ci</a> used to get some of the way there, but Travis CI recently yanked the rug out from under FOSS projects. I believe there is active work to make that repo support other CI systems. (More hands would probably help.)<br>
<br>
A possible compromise for bounds: use ^>= bounds, raising the lower bound when you either a) need something from a new version, or b) move to a new major version? If you remain open to metadata revisions that relax the lower bound if needed, that might be OK? Again, spitballing, and I expect some kind soul to point out the flaws in this plan.<br>
<br>
Best,<br>
<br>
-- Jack<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Pasqualino "Titto" Assini<br><div><a href="http://networkpolitics.svbtle.com" target="_blank">http://networkpolitics.svbtle.com</a></div><div><a href="http://quid2.org/" target="_blank">http://quid2.org/</a><br><br></div></div></div></div></div>