Can't be used to bootstrap GHC

[ndmitchell]

Can't be used to bootstrap GHC

[RyanGlScott]

There's a fourth option here as well:

4. Use head.hackage to build dependencies with GHC HEAD.

Indeed, I added a head.hackage patch for cabal-doctest here for precisely this reason.

cc @phadej

[ndmitchell]

I don't use head.hackage, so it doesn't fit my workflow, so while it might be enough for some people I'd still need another solution.

[RyanGlScott]

While I'm sympathetic to the desire to have shake build with GHC HEAD at all times, keeping cabal-doctest in sync with HEAD can prove to be a nightmare due to how quickly the Cabal API changes in its development process. We'd have to constantly be churning out new Hackage releases of cabal-doctest to stay in line with the moving target of HEAD. More than likely, most of those releases would bitrot by the time the next major release of GHC came out, which would require time and effort to go back and make metadata revisions to repair the old, broken versions of cabal-doctest that no longer compile with the new major release.

This is why I strongly encourage people to use head.hackage, since it allows people who use GHC HEAD to stay on top of the latest development changes without spamming Hackage with a bunch of releases to stay in sync with HEAD. It also means that developers don't have to worry about incurring dependencies as much as they used to, since head.hackage can ensure that they're always building without issues.

[phadej]

5th option: remove build-type: Custom. It's either means ripping of doctests or make working `cabal doctest` (which might be GSOC project this year). For `shake`, I'd stay out of using `build-type: Custom` packages. They are difficult in bootstrapping-like situations. Also packages depending on `template-haskell`, and ...

…

Sent from my iPhone

On 5 Feb 2019, at 13.04, Ryan Scott ***@***.***> wrote: While I'm sympathetic to the desire to have shake build with GHC HEAD at all times, keeping cabal-doctest in sync with HEAD can prove to be a nightmare due to how quickly the Cabal API changes in its development process. We'd have to constantly be churning out new Hackage releases of cabal-doctest to stay in line with the moving target of HEAD. More than likely, most of those releases would bitrot by the time the next major release of GHC came out, which would require time and effort to go back and make metadata revisions to repair the old, broken versions of cabal-doctest that no longer compile with the new major release. This is why I strongly encourage people to use head.hackage, since it allows people who use GHC HEAD to stay on top of the latest development changes without spamming Hackage with a bunch of releases to stay in sync with HEAD. It also means that developers don't have to worry about incurring dependencies as much as they used to, since head.hackage can ensure that they're always building without issues. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[RyanGlScott]

Option (5) also sounds reasonable. Is there a way to remove the custom Setup.hs stanza while still retaining the ability to run doctests locally (within the heaps repo itself)?

[RyanGlScott]

@ndmitchell, #14 features a version of heaps without the cabal-doctest dependency. Would this work for your needs?

[ndmitchell]

5. would be the best option, and #14 gets there. I think @phadej is right that Shake should avoid build-type Custom.

[RyanGlScott]

I've released heaps-0.3.6.1 to Hackage without a cabal-doctest dependency. Let me know if anything else is required on heaps' end.