Re: packaging postgrest, haskell patches

[Robert Vollmert]

Hi,

On 6. Jul 2019, at 03:08, Timothy Sample <address@hidden> wrote:
> Ludovic Courtès <address@hidden> writes:
>> Robert Vollmert <address@hidden> skribis:
>>> * I’m a bit unclear on where to file the various new
>>>  ghc-* packages. Currently it’s more or less aribtrarily spread
>>>  across a bunch of modules, compare the github link above.
>>> 
>>>  Should I go ahead with moving towards an organization as
>>>  suggested here?
>>>    https://lists.gnu.org/archive/html/guix-devel/2019-06/msg00181.html
>> 
>> I think we should get input from Timothy, Ricardo, and anyone with an
>> interest in Haskell packaging.  But I think you’re a good candidate for
>> the honorific position of Haskell Package Overseer.  :-)
> 
> Since their first contribution I’ve thinking to myself “I hope Robert
> sticks around long enough to become the Haskell Package Overseer.”  :)

Hah. Thanks for the votes of confidence. I can’t quite promise to stick
around, but happy to give this a shot. :)

>> Regarding the module organization, I think it makes sense to add more
>> haskell-*.scm modules, though I’m unsure about the hackage splitting you
>> propose—is it helpful to split it like this?
> 
> First, I missed the “haskell-apps” migration.  I couldn’t find any
> discussion about it on the lists (maybe it was discussed and I just
> can’t find it).  Since one of Robert’s suggestions is to revert it, it
> would be helpful to know what prompted that change.  (I assume there is
> some cost to bringing in the Haskell modules from the “version-control”
> module, but I don’t know enough about it.)

I’m not sure I’d actually want to merge haskell-apps back. There’s one
very good reason to keep them apart, since packages in haskell-apps
would typically be packaged without the ghc- prefix. That’s a nicely
clear-cut criterion for keeping them separate.

> To be honest, I don’t use the current categorization system for Haskell
> or for anything, really.  I just search.  That being said, organizing
> the Haskell packages alphabetically would be different from everything
> else.  I would prefer to follow Python and Perl, if only for the sake of
> consistency.  This is a very slight preference, though.

To summarize the python approach:

- python.scm for the compiler/interpreters
- python-<topic>.scm for modules grouped by topic
- python-xyz.scm for all the rest

Is that about right?

As you note, the current categorization system doesn’t seem to be
particularly useful. There’s no immediate way to get from a package name
or description to the corresponding module, except for grepping through
or waiting for the `guix package` error suggestion. Since the most common
use-case for finding the module seems to be figuring out what you need
to import in order to use a package, I’d suggest trying to make that
step easier. Which might be achieved by

(a) putting everything in haskell-xyz.scm
(b) splitting up by module name prefix (as a work-around guile’s poor
scaling with module size)

Any other ideas?

> I think that splitting off the Stackage LTS packages would be a little
> bit helpful for maintenance, and a little bit annoying for use, but not
> significant either way.  Maybe I missed the point here?

I’m happy to let that part rest a bit. The point here is that I feel the
current state is a bit hard to maintain with respect to updates. It would
be nice to see explicitly why and where we diverge from the stackage
version set. E.g. the recent update of ghc-ansi-terminal to a
stackage nightly version

(https://www.stackage.org/lts-13.27/package/ansi-terminal-0.8.2,
commits cbff89d126bf5985cfa4884f543c0908c437ff41 and
4e3ebbfb1649063bcc0f350523868c667e6699dd)

makes a bit of a mess of the dependency graph and might have been avoided
if there were clear criteria and a clear organization. (I still need to
figure out precisely what’s going on there, but I’m getting build failures
now due to the mixed depedencies on ansi-terminal-0.9.1 and ansi-terminal-0.8.2
via different intermediate packages.)

Robert