Open alaendle opened 4 months ago
It's not that simple, because it's the same model as HLS (one binary per GHC version). What we need is a print-api
wrapper executable that calls the appropriate binary in your path.
I fear that with print-api available on Hackage, people will mistakenly believe that they can just cabal install
it. But in fact they will build it for a particular GHC version, and will have to rebuild it for another GHC version that another project may use.
cabal install
from Hackage is not the correct distribution channel for this program.
Maybe I haven't understood the full scope of the problem, but I at least don't expect such tools to work on different GHC versions - I would have seen this in a category with e.g. weeder (and I believe there exist a lot of other similar tools that depend on the GHC version they are build with).
So I still think it would be worth publishing (and in terms of behaviour (the ghc version thing) would also fit into the ecosystem).
(but for sure that is just my perspective - mainly driven by the use of a defined environment of a development container, where its guaranteed to only have one GHC version; and where I wish for a "standardized" installation method like cabal/stack install
)
Please feel free to just close this issue if you disagree.
I'll keep this ticket open, but for the moment I will try to focus on modularity and filtering. If you need a published release, and your platform is provided by GHA, then you will find your binary at: https://github.com/Kleidukos/print-api/releases/tag/v0.1.0.1
There's a lot of stuff for me to figure out but I'll come back to it. :)
And maybe even add it to the stackage index? Just to make it easier for end-users to build the binary via a simple
cabal install print-api
orstack install print-api
.