Re: on cabal revisions

[Robert Vollmert]

On 13. Jun 2019, at 16:25, Timothy Sample <address@hidden> wrote:
> 
>> I remembered one more: guix refresh. As far as I understand, it works
>> only on the level of the source field, thus having the revision there
>> would help make it revision-aware. I’m unsure though whether the
>> snippet approach actually improves things here — probably the refresh
>> code would see the resulting gexp and not the raw data.
> 
> This is a very good point!  Unfortunately, AFAICT, the refresh mechanism
> only works on the level of versions.  It has no support for automated
> patches or snippet changes.  It looks like updating the Cabal revision
> using the refresh script would require one or two far-reaching changes.
> Are there other package repositories that use a release-with-patches
> style?  Having another example would make it easier to design at the
> right level of abstraction.
> 
> Now I think that we should have a good plan for refreshing before making
> a bunch of changes to the Cabal revision stuff.  Otherwise, we might
> have to change everything again if and when we make refreshing work.
> 
> Thoughts?

I agree that reworking the revision thing shouldn’t happen first. I’m
happy to understand how it might work for now.

Is “guix refresh” even a good approach for the haskell packages? There’s
a lot of work being done to put consistent sets of haskell packages, e.g.
the whole stackage project. Does Guix mean to replicate this work, or would
it maybe be a good choice to follow stackage sets?

How big is the diff between the current haskell package definitions and
the result of guix hackage import? It would be tempting to consider most
as an output of guix hackage import, and to refresh them by reimporting,
possibly based on a version set pulled from stackage.

Hmm another tangential question: Is there any particular system to the
splitting of gnu/packages/haskell*.scm?

haskell.scm itself is huge — does this have performance implications? I’ve been
wondering whether guile scales well with module size. It appears that circular
imports between package modules are not a problem? Personally I’d like to
see the haskell compiler in a different module from hackage modules. Other
than that, keeping our own categorization seems wasteful, why not one
haskell-hackage.scm that’s sorted alphabetically by package name?

Robert