Get the Kmett-verse off custom setups

[ezyang]

@ekmett has many packages, even "low level" ones, which use custom setup scripts. Examples:

• https://hackage.haskell.org/package/distributive
• https://hackage.haskell.org/package/comonad
• https://hackage.haskell.org/package/zippers

Grepping for generateBuildModule on Hackage will give you quite a parcel.

The boilerplate for these setup scripts is quite similar. This function is copy pasted quite a bit:

generateBuildModule :: Verbosity -> PackageDescription -> LocalBuildInfo -> IO ()
generateBuildModule verbosity pkg lbi = do
  let dir = autogenModulesDir lbi
  createDirectoryIfMissingVerbose verbosity True dir
  withLibLBI pkg lbi $ \_ libcfg -> do
    withTestLBI pkg lbi $ \suite suitecfg -> do
      rewriteFile (dir </> "Build_" ++ testName suite ++ ".hs") $ unlines
        [ "module Build_" ++ testName suite ++ " where"
        , "deps :: [String]"
        , "deps = " ++ (show $ formatdeps (testDeps libcfg suitecfg))
        ]
  where
    formatdeps = map (formatone . snd)
    formatone p = case packageName p of
      PackageName n -> n ++ "-" ++ showVersion (packageVersion p)

testDeps :: ComponentLocalBuildInfo -> ComponentLocalBuildInfo -> [(InstalledPackageId, PackageId)]
testDeps xs ys = nub $ componentPackageDeps xs ++ componentPackageDeps ys

Any reason why Paths can't support this?

I've also seen it used for Haddock:

haddockOutputDir :: Package p => HaddockFlags -> p -> FilePath
haddockOutputDir flags pkg = destDir where
  baseDir = case haddockDistPref flags of
    NoFlag -> "."
    Flag x -> x
  destDir = baseDir </> "doc" </> "html" </> display (packageName pkg)

I don't know what kind of bug this is working around. Eek!

It would be great if the Kmett-verse could get off Custom scripts. It will take time, because they have big Cabal support windows. But the change starts here.

[ekmett]

I also have a few scripts that copy an extra image or something into the haddock directory.

I think the lens script does so.

[23Skidoo]

I also have a few scripts that copy an extra image or something into the haddock directory.

Don't we have extra-doc-files for that?

[ekmett]

Since around 1.18 right? I've yet to be able to make the switch.

[phadej]

@ezyang, the deps (and autogen_dir) variable is needed to drive doctests, see

• https://github.com/ekmett/bound/blob/master/Setup.lhs
• https://github.com/ekmett/bound/blob/master/tests/doctests.hs

I.e. if there would be declarative way to run doctests: profit.

[23Skidoo]

@ekmett Yes, since 1.18: 49a2be9, 4502e90. Though it looks like we don't have a version check for it in D.PD.Check.

[23Skidoo]

Though it looks like we don't have a version check for it in D.PD.Check.

Fixed in #3825.

[RyanGlScott]

@phadej: Re the declarative way to run doctests: would #2327 give us this ability?

[phadej]

@RyanGlScott, yes, AFAICS the doctests are the only reason Edward's packages use Custom setup.

[phadej]

rescheduling for 3.0.

[osa1]

What's the next step here? Looking at the referenced tickets and PRs above, it seems like they're all closed/merged. Can we just go ahead and simplify custom setups of kmett packages?

[quasicomputational]

Not likely. cabal doctest doesn't play well (or at all) with new-style commands; #4500 is the issue for getting doctest to work with new-build (or stack, for that matter) without hacks.

[ekmett]

Can we just go ahead and simplify custom setups of kmett packages?

I won't be able to do so until I can expect all the users in my current support window are on a version of cabal with those patches integrated. Even that clock really can't start until after, as noted, the problems with cabal doctesting new-builds is resolved. =/

[hvr]

@ekmett well, do your users actually need to be able to invoke the doctest-testsuite with legacy cabal versions? It's quite possible that we can implement this in a similar way to the custom-setup which is ignored by cabal versions not gnostic to it.

[ekmett]

@hvr That might work.

[RyanGlScott]

Using cabal-docspec, we've managed to remove the use of custom Setup scripts for most repos in the Kmettiverse. I'm not sure if that's enough to warrant closing this issue—your call.

[ekmett]

I'm willing to declare intent to move the rest to cabal-docspec.

[ulysses4ever]

I built an intersection of two lists

1. Hackage grep result for generateBuildModule (as suggested above, this is a good evidence of a Edward's work)

2. List of packages where Edward is listed as a maintainer

Here's the result with comments:

• hash (last uploaded 2013)
• parsec-parsers (last uploaded 2013)
• sparse (last uploaded 2015)
• structures (last uploaded 2014)
• tables (last uploaded 2015)

So, these all look kinda dated. I propose we close this issue as completed (thanks to maintainers of respective packages, mostly Ryan).

[Mikolaj]

Well done. Thank you. Closing.