[Haskell-cafe] Do something about Cabal?

Fri Dec 11 12:48:20 UTC 2020

I always wondered: do we need a package management system at all?

Putting aside for a second the problem of interfacing with C or other
external dependencies.

What about a system where every source file is automatically annotated with
a unique hash and all the required LANGUAGE extensions.

For example:

-- State explicitly any non-standard language extension
{-# LANGUAGE MultiParamTypeClasses ,PatternSynonyms ,RankNTypes #-}

-- Add to the module name its hash (calculated on its source contents,
ignoring comments)
module App.Main.K306f1981b41c

-- Import a module, specifying the exact version
import Data.Maybe.K306f1981823d

....

main: ...

Finally, we publish it on a shared content addressable system (hackage
like).

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:

lookMaNoPackages run App.Main.K306f1981b41c

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.

And a modern tool like haskell-language-server could automate the
hashing/annotations making it convenient to use.

Would this work?

       titto

Il giorno ven 11 dic 2020 alle ore 12:40 Jack Kelly via Haskell-Cafe <
haskell-cafe at haskell.org> ha scritto:

>
> December 11, 2020 7:50 PM, "Bardur Arantsson" <spam at scientician.net>
> wrote:
>
> > On 10/12/2020 22.07, Jack Kelly via Haskell-Cafe wrote:
> >
> >> [snip]
> >
> > Absolutely agreed that there is currently to "Right Answer"(TM) wrt.
> > Cabal or Stack. They do different things well/badly. Until we get a tool
> > that can do everything the schism will probably remain.
> >
> > (And that's not even talking about issues like technical debt in each of
> > the code bases, etc.)
>
> I'm glad my message was taken in the right way.
>
> > My problem here is that Cabal hasn't provided some very useful the
> > features that YAML does out of the box, namely the ability to define
> > arbitrary snippets of package configuration and to refer to them from
> > multiple places. Examples:
> >
> > If I maintain a cohesive set of 5 packages, I need to duplicate various
> > bits and bobs of information in 5 different places:
> >
> > [snip things that really should be DRY'd up by a modern build tool]
>
> 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.
> https://cabal.readthedocs.io/en/latest/cabal-package.html?#common-stanzas
>
> 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.
>
> > This is tedious at best and outright wrong
> > at worst (inconsistent version bounds).
> > In no way am I advocating for YAML specifically.
> > (Dhall could work here since you can at least do inclusions and reuse in
> > a generic way. Plus it has fully defined semantics plus implementations
> > in at least a couple of langauges, Haskell and Scala.)
>
> 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.
>
> >> - Many stack projects do not provide bounds on dependencies
> > I posit that at least a *part* of the problem here is tedium for
> > maintainers (see above), but while we're at it: I'm not sure manually
> > maintaining bounds is at all scalable nor particularly "correct" (for
> > lower bounds, esp.) unless one is *super*-vigilant about what bits of a
> > dependency are *actually* in use.
> >
> > FWIW, I do try to do this for my packages, but I'm very confident that
> > all of my packages probably have misleading lower bounds.
> >
> > It seems to me that some automated tooling is needed here, e.g. to try
> > building/testing with e.g. all deps at the lower bound, all deps at the
> > highest bound, etc.
>
> No doubt. The only way to have a hope of doing this is with a CI matrix.
> https://github.com/haskell-CI/haskell-ci 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.)
>
> 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.
>
> Best,
>
> -- Jack
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

-- 
Pasqualino "Titto" Assini
http://networkpolitics.svbtle.com
http://quid2.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201211/12c797cc/attachment.html>