all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Robert Vollmert <rob@vllmrt.net>
To: Timothy Sample <samplet@ngyro.com>
Cc: guix-devel@gnu.org
Subject: Re: packaging postgrest, haskell patches
Date: Mon, 8 Jul 2019 09:36:46 +0200	[thread overview]
Message-ID: <FFD1C238-7554-412F-ABB7-5B889A154A46@vllmrt.net> (raw)
In-Reply-To: <87d0iot1ek.fsf@ngyro.com>

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

      parent reply	other threads:[~2019-07-08  7:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-30 21:09 packaging postgrest, haskell patches Robert Vollmert
2019-07-05 21:31 ` Ludovic Courtès
2019-07-06  1:08   ` Timothy Sample
2019-07-06  9:31     ` Ricardo Wurmus
2019-07-08  7:36     ` Robert Vollmert [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=FFD1C238-7554-412F-ABB7-5B889A154A46@vllmrt.net \
    --to=rob@vllmrt.net \
    --cc=guix-devel@gnu.org \
    --cc=samplet@ngyro.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.