Upload packages to hackage

[knothed]

Do you plan on releasing a new version and distributing the packages on hackage in the near future? That would allow library authors using these packages to also distribute their libraries on hackage.

[Ericson2314]

We'll have to rework the bootstrapping so one can in fact build from hackage (RIP) but then yes we should.

[sgraf812]

So what's an estimate as to when that rework is done? Is it blocked on haskell/cabal#7189? If so, that sounds pretty road blocky.

• Plans that use bootstrapping to break cycles cabal#7189

[andreasabel]

ATTN: @Ericson2314 @int-index

[int-index]

I have released happy-2.0 as a set of package candidates. You can test them by adding the following lines to your cabal.project:

packages:
  https://hackage.haskell.org/package/happy-2.0/candidate/happy-2.0.tar.gz
  https://hackage.haskell.org/package/happy-grammar-2.0/candidate/happy-grammar-2.0.tar.gz
  https://hackage.haskell.org/package/happy-tabular-2.0/candidate/happy-tabular-2.0.tar.gz
  https://hackage.haskell.org/package/happy-codegen-common-2.0/candidate/happy-codegen-common-2.0.tar.gz
  https://hackage.haskell.org/package/happy-backend-glr-2.0/candidate/happy-backend-glr-2.0.tar.gz
  https://hackage.haskell.org/package/happy-backend-lalr-2.0/candidate/happy-backend-lalr-2.0.tar.gz
  https://hackage.haskell.org/package/happy-frontend-2.0/candidate/happy-frontend-2.0.tar.gz

And the following line to your .cabal file:

build-tool-depends: happy:happy >= 2.0

This should ensure that your .y files are built with happy-2.0. You can confirm this by using cabal build -v and inspecting the logs to see what happy binary is used to build your .y files.

If I see users confirm that happy-2.0 is working well for them, I will publish the package candidates as normal packages.

[andreasabel]

@int-index : Could you please also upload the documentation for these candidates?
E.g. I looked at the happy-grammar source and found that it only exposes the Happy.Grammar module, but fails to document it.
I don't think these packages are in a releasable state if they don't make an effort to document.
After all, why split the happy executable into many packages if you do not intend folks to use them? (Maybe you intend them to be used, but then this intention should be expressed by writing docs.)
With happy being just one exectuable, all that was needed to document was the CLI. This will drastically change if you release an API.