Re: [Haskell-cafe] Do something about Cabal?

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@haskell.org> ha scritto:

December 11, 2020 7:50 PM, "Bardur Arantsson" 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/