packaging postgrest, haskell patches

packaging postgrest, haskell patches

[Robert Vollmert]

Hi,

now that postgrest 6.0.0 has made it to hackage:

  http://hackage.haskell.org/package/postgrest

I’d like to submit my packaging of it for inclusion
in guix. The current state is visible here:

  https://github.com/robx/guix-postgrest

Some questions/open issues:

* I’ve submitted a few patches to the haskell packages
  that are required for this:
  - #36108 and #36038 fix package conflicts between ghc-included
    modules and packaged modules
  - #36499 updates the dependency ghc-primitive
  Should I wait for those to be merged, or lump them all
  together?
* 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

Cheers
Robert

Re: packaging postgrest, haskell patches

[Ludovic Courtès]

Hello Robert!

Robert Vollmert <rob@vllmrt.net> skribis:

> Some questions/open issues:
>
> * I’ve submitted a few patches to the haskell packages
>   that are required for this:
>   - #36108 and #36038 fix package conflicts between ghc-included
>     modules and packaged modules
>   - #36499 updates the dependency ghc-primitive
>   Should I wait for those to be merged, or lump them all
>   together?
> * 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.  :-)

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?

Thoughts?

Ludo’.

Re: packaging postgrest, haskell patches

[Timothy Sample]

Hi Ludo and Robert,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello Robert!
>
> Robert Vollmert <rob@vllmrt.net> skribis:
>
>> Some questions/open issues:
>>
>> * I’ve submitted a few patches to the haskell packages
>>   that are required for this:
>>   - #36108 and #36038 fix package conflicts between ghc-included
>>     modules and packaged modules
>>   - #36499 updates the dependency ghc-primitive
>>   Should I wait for those to be merged, or lump them all
>>   together?
>> * 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.”  :)

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

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

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.

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?

My (slight) preference is just to copy Python, including getting rid of
“haskell-apps” (unless it is a necessary hack), and splitting off
“haskell-xyz” from “haskell”.


-- Tim

Re: packaging postgrest, haskell patches

[Ricardo Wurmus]

Timothy Sample <samplet@ngyro.com> writes:

>> 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, me too :)

> To be honest, I don’t use the current categorization system for Haskell
> or for anything, really.  I just search.
[…]
> My (slight) preference is just to copy Python, including getting rid of
> “haskell-apps” (unless it is a necessary hack), and splitting off
> “haskell-xyz” from “haskell”.

Same here.

-- 
Ricardo

Re: packaging postgrest, haskell patches

[Robert Vollmert]

Hi,

On 6. Jul 2019, at 03:08, Timothy Sample <samplet@ngyro.com> wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
>> Robert Vollmert <rob@vllmrt.net> 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