Upadte README

[sol]

No description provided.

[andreasabel]

cabal install is not really compatible with a multi-GHC environment. I will just install doctest that works with the current GHC. I would expect that rather one defines doctest as a dependency in the .cabal file and then it will be installed locally only, for the GHC version that is used to cabal test the project.

[andreasabel]

Rather than installing doctest, could it not some be located in the build-tree of the SUT?

Update: SUT = "system under test". Yeah, silly abbreviation, sorry.

[sol]

SUT?

[sol]

https:/sol/doctest-example is an alternative approach. That is add a doctest flag to .cabal / package.yaml:

flags:
  doctest:
    manual: True
    default: False

when:
  condition: flag(doctest)
  build-tools: doctest
  dependencies:
    - QuickCheck
    - template-haskell

and then invoke doctest like so:

cabal build -fdoctest && cabal exec -fdoctest -- cabal repl -fdoctest --with-ghc=doctest

While this is more robust, it is not easier to document + there will be a bunch of people that will reject the "idea of modifying .cabal just for tests", even though, guarded behind a flag, it has no tangible "cost" that I'm aware of.

An other option of course would be to install doctest to the current working directory, somewhat cleaner maybe, but you still need to do it before each invocation, assuming that you sometimes switch GHC versions.

I'm not aware of anything that would e.g. tell cabal exec to bring some executable into scope via command-line options. Arguably that is what we would want.

Just to be clear, you don't have to re-install doctest before each invocation. If doctest was built with a different version GHC than what you use for e.g. cabal build then things will still work:

• doctest will run using the version of GHC it was built against
• cabal repl may need to rebuild dependencies for that version of GHC, which is fine, as long as it's not ghc-paths. At the point ghc-paths gets built via cabal repl --with-ghc=doctest, you potentially get into trouble.

[sol]

@andreasabel subject under test, I guess. Not that I'm aware of. At least not without modifying cabal.project[.local]. If there is a way, I would be eager to learn about it.

[andreasabel]

I agree I would not want to add such a flag to my projects.
I only know of the build-tool-depends: doctest:doctest trick to pass in executable doctest to a testsuite.

It might be worthwhile to refer to https:/Hexirp/doctest-driver-gen as well as a way to integrate doctest.

Taking a step back, I would want my doctest-suites to run by a simple invocation of cabal test or stack test, nothing more than that. This way, they integrate smoothly with both stackage and haskell-ci. Anything more complicated needs manually fiddling all the time, which I find tiresome.

[sol]

@andreasabel the advantage of using cabal repl is that it works reliably (modulo cabal repl bugs of course, of which there hasn't been a shortage in the past neither). I don't think there is a way to make a cabal test suite work with Paths_* (at least I'm not aware of anything).

[sol]

I'm going to merge this, not because I think it's beautiful or perfect, but because it's the best thing I can come up with considering the current "state of cabal".

Let's see how long it will work. cabal has been notorious in breaking other peoples code in the past (for me alone, every of my major projects: doctest, hpack, hspec-discover, tinc, ... you name it). Often times deliberately (it's on the public record, @hvr saying "it's only test suites that break", every single test suite that uses hspec-discover, the irony being that the whole build tool story is basically an hspec-discover story, as that was the only widely used "build tool" at that time besides things that already ship with ghc). So you build a feature but you don't care about your single most important client?

I'm not saying there is an agenda, but @phadej being involved with cabal which breaks doctest then writing a doctest replacement to address this breakage is, I don't know, don't ask me, nice?

At some point I may just follow @snoyberg's and @chrisdone's lead and call it a day.

[sol]

All that said, if somebody comes up with a better way to do it, I'm still very eager to learn about it.

Specifically: Is there a way to bring an executable into scope (e.g. with cabal exec) without depending on it?

One more thing. stack repl instructions are still missing. PRs welcome.

[sol]

For the public record, I deleted a comment by @phadej, because I'm not going into a discussion on whether it's "necessary" to break other peoples code at will or not. For the interested reader, here is a discussion that I think is evident of how willing the cabal team was to prevent breakage of hspec-discover:

haskell/cabal#5105

And for what it's worth, I don't think the discussion on that issue was evidence based:

haskell/cabal#5105 (comment)

And for historic context and the LOLs of it, you may want to grab some popcorn 🍿 and beer 🍻 and read through the discussion of one of the very first PRs to cabal by @jmillikin (who I think has left the community a long time ago and apparently is doing Rust now?):

haskell/cabal#2

PS: @phadej just to be very clear, I did not accuse you of anything. If you want to help I'm happy to have a discussion at cabal/cabal on how to minimize breakage of hpack due to cabal requiring users to list Paths_* under autogen-modules.

[andreasabel]

And for historic context and the LOLs of it, you may want to grab some popcorn 🍿 and beer 🍻 and read through the discussion of one of the very first PRs to cabal by @jmillikin

I followed this lead and read through this discussion. This PR was almost bikeshedded to death. However, I have to say that I like cabal get -s better than cabal fork, because under "fork" I understand "an upstream clone" rather than simply a "clone". [On the other hand, I never discovered cabal get -s until just now. So maybe cabal clone or s.th. would have helped discovery. Fact is, I hardly use plain cabal get, rather, I clone from github. Yet cabal get -s could speed the cloning up.] In the end, one may still wonder whether that amount of bikeshedding was worth the wording change from fork to get -s, if as a byproduct a contributor was scared away...