Hi, Nicolas Goaziou <[email protected]> writes:
> > Timothy Sample <[email protected]> writes: > >> We already have “hspec-discover” without the “ghc” prefix. The two >> packages look identical to me – is this an unintentional copy? > > Oh! I hadn't noticed! > > Well, is there any strong reason to use "hspec-discover" over > "ghc-hspec-discover", besides that it already exists? The loose convention is that libraries have the prefix, and programs don’t. The “hspec-discover” package was added before my time, but I guess whoever added it was following that convention. > For the arguments in favor of using ghc-hspec-discover: > - every other "hspec" package uses the "ghc-" prefix, > - the hackage importer names it, > - the hackage importer will add "ghc-hspec-discover" as an input anyway. That is definitely a problem. From my experience, “hspec-discover” is often missed by the importer because it is put in “build-tool-depends” instead of “build-depends” in the Cabal file. Ideally, the importer would know to add it from “build-tools-discover” and it would know what it should be named. > So what about deprecating "hspec-discover" in favor of > "ghc-hspec-discover"? I did a quick scan of the “text-conversions” source code, and it doesn’t seem to use “hspec-discover” as a library. It looks like it’s just a mistake in the Cabal file. Between the convention and the fact that “hspec-discover” is almost always used as a program instead of a library, I would say that it’s okay the way it is. Beyond that, it would be quite a bit of churn to change it with very little benefit. > Thanks for the heads up! No problem. Thanks for committing packages! -- Tim
