Re: on cabal revisions

[Timothy Sample]

Hi Robert,

I don’t have a lot of time, so here’s a “hot take” on the points you
bring up.

Robert Vollmert <address@hidden> writes:

> 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?

We mostly do this already.  There is a Stackage importer, and a little
while ago I updated most of our Haskell packages to their LTS 12
versions.

> 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.

IIRC, Nix automatically imports all Haskell packages from Hackage (I’m a
little fuzzy on the details, though).

Our refresh script knows about Stackage, so you can use it to keep
packages up to date with Stackage.  One of the main issues with
automatic package maintenance in Guix is that we have some
unconventional, non-technical and semi-technical requirements on our
packages.  We need to follow the FSDG (Free Software Distribution
Guidelines); we try and make sure that everything has a useful synopsis
and description; and we try to make sure everything is bootstrappable
and reproducible.  I say “unconventional” above because there are often
upstream issues with these things that need to be fixed manually.

The reason I bring these up is that we would have to develop some
mechanism to maintain documentation changes, extra license information,
and any other changes we make.  Basically, we can’t “just” reimport
every time.  I also worry that trying to move in that direction would
result in less care taken to maintain our own standards of quality,
since the tools would put pressure on us to just use whatever we get
from upstream.

This is just me thinking out loud, of course.

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

Not beyond the obvious one (that is, crypto packages go in “crypto”).

> haskell.scm itself is huge — does this have performance implications?

Yes.  It is an ongoing problem with Guix, and one of the reasons we
split up the files in the first place.  If you want to know more, there
have been many discussions on this list.

> 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.

We are moving towards this in general.  The “guile.scm” and
“guile-xyz.scm” split is a recent example of this.

> Other
> than that, keeping our own categorization seems wasteful, why not one
> haskell-hackage.scm that’s sorted alphabetically by package name?

The subcategories (e.g., “web”) are mostly for performance reasons,
AIUI.  I’m not sure why packages are not alphabetical.  I don’t think
there is any formal organization to the packages within modules.

Hope that helps!


-- Tim