haskell package organization (Re: on cabal revisions)

[Robert Vollmert]

On 14. Jun 2019, at 22:24, Ricardo Wurmus <address@hidden> wrote:
> Timothy Sample <address@hidden> writes:
>> 
>> 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.
> 
> At the beginning we just had all the latest packages from Hackage and it
> took considerable time and effort to upgrade them all to a consistent
> LTS set.
> 
> This makes the review of updates to ghc-* packages a little slower for
> me because these packages really ought to be upgraded together so that
> they closely resemble whichever LTS version we’re following.

[ This is really in reply to multiple threads of this discussion. Also
  it’s based on my limited understanding of issues — please correct my
  misunderstandings. E.g. I don’t quite understand how guile works around
  circular imports. Finally, for my motivation: I’m packaging a few
  Haskell programs that pull in quite a few new libraries, and would
  rather use that opportunity to make matters better not worse. ]

So what do you all think of some organization like the following:

gnu/packages/haskell.scm:
  Haskell compilers (ghc), and their dependencies if any. Shouldn’t import
  any of the the other haskell modules.

gnu/packages/haskell-stackage-*.scm:
  Various Haskell library modules (ghc-*) that are consistent with some
  stackage set (LTS 12 currently).

gnu/packages/haskell-other.scm:
  Various Haskell library modules that are either on a non-LTS version,
  or not on stackage at all. This might include alternate versions of
  stackage modules, under a different name.

gnu/packages/haskell-tools.scm:
  Haskell executables that are Haskell specific. E.g. hlint,
  hspec-discover, ….

gnu/packages/*.scm:
  Programs that happen to be built using the Haskell build system. E.g.
  things that are currently in haskell-apps.scm: darcs, git-annex.

The idea would be that the stackage updates would be clearly targeted
to those haskell-stackage files.

My personal preference for the haskell-stackage-*.scm files would be to
simply split them by name prefix, e.g.

  haskell-stackage-abc.scm, haskell-stackage-def.scm

so that they are of manageable size. (I think the current categorization
into haskell-web, haskell-crypto etc. causes quite a bit of cognitive
overhead for little benefit: Where should I file this oauth package?
Where do I import it from?)

Robert