search

msgpack / msgpack-haskell

Haskell implementation of MessagePack / msgpack.org[Haskell]
http://hackage.haskell.org/package/msgpack
138 stars 80 forks source link

Add to stackage #62

Open nh2 opened 8 years ago

nh2 commented 8 years ago

Hey, would you mind adding this library to Stackage?

I'd like to add my library that depends on it to Stackage.

2mol commented 5 years ago

Any update on this? Considering that the msgpack organization might not be completely familiar with the Haskell ecosystem, could we describe the steps to add this to stackage? Or maybe the instructions in stackage's MAINTAINERS.md is sufficient?

The msgpack website attributes the implementation to @rodrigosetti however it seems to be @tanakh who did the bulk of it.

Option B would be to add the package ourselves without being the maintainer, as described (but discouraged) in the document linked above. Would there be any objections to that?

Otherwise switch your library to the fork at https://github.com/TokTok/hs-msgpack?

rodrigosetti commented 5 years ago

@2mol the attributed is for a different implementation: https://github.com/rodrigosetti/messagepack

2mol commented 5 years ago

Oh, sorry for pinging you then, but thanks for the clarification!

hvr commented 5 years ago

Unfortunately I can't do this myself as I've been banned from Stackage and can't file any submissions nor comment on any tickets there.

blocked

blocked2

2mol commented 5 years ago

Aight, I'll do a PR under my name to get it included, but one of these day's we'll all sit together with a nice cup of tea, commit to a better style of disagreements, and then collectively unblock each other.

edit: https://github.com/commercialhaskell/stackage/pull/4471

2mol commented 5 years ago

PR is in progress, however currently msgpack-idl fails on the version bounds for template-haskell for current stackage nightly.

hvr commented 5 years ago

@2mol currently only msgpack/msgpack-aeson/msgpack-rpc are expected to work (this is also why the cabal.project config has only those 3 active for CI)

2mol commented 5 years ago

Ah, I don't think stack init reads the cabal.project file. Any experience with how to tell stack to exclude those files in an automated way?

Deleting those subfolders for now and then again running stack init --resolver nightly gives

Resolver 'nightly-2019-04-10' does not have all the packages to match your requirements.
    binary-conduit version 1.3.1 found
        - msgpack-rpc requires >=1.2.3 && <1.3
    conduit version 1.3.1.1 found
        - msgpack-rpc requires >=1.2.3.1 && <1.3
    conduit-extra version 1.3.1.1 found
        - msgpack-rpc requires >=1.1.3.4 && <1.3
    int-cast not found
        - msgpack requires >=0.1.1 && <0.3

So it seems that we could bump some version bounds, but also need to add int-cast to stackage.

hvr commented 5 years ago

While there is an unresolved Stack ticket about supporting the standard cabal.project file it shouldn't matter for the task at hand as I wouldn't recommend working from the Git repo which is currently in the midst of a larger refactoring; afaik Stackage only deals with released artifacts; so try to grab the respective releases from Hackage from

respectively; you can conveniently unpack the most recent releases into your local folder simply via cabal like so and work from there

$ cabal get msgpack msgpack-aeson msgpack-rpc
Unpacking to msgpack-1.0.1.0/
Unpacking to msgpack-aeson-0.1.0.0/
Unpacking to msgpack-rpc-1.0.0/
2mol commented 5 years ago

Ah, that leaves the version bounds and int-cast. I will add the latter too and ask for help with passing the checks. Could you bump the former, or is there something that speaks against it?

DanBurton commented 5 years ago

Unfortunately I can't do this myself as I've been banned from Stackage and can't file any submissions nor comment on any tickets there.

@hvr even if you could, would you? I have been operating under the understanding that you would prefer not to be pinged by Stackage stuff when feasible. I for one try to respect these wishes and open issues on your stuff only if there is a way to frame the issue as one which is beneficial to the Haskell ecosystem as a whole, and not just specifically to Stackage.

hvr commented 5 years ago

@2mol the conduit-related bounds in message-rpc are indeed intentional as iirc it isn't compatible with more recent versions of the APIs; but I am not familiar enough with the conduit-verse to have fixed it yet. So maybe leave out msgpack-rpc for now; I'll try to get it working again when I have time again (or somebody else might be able to beat me and file a PR; it's probably easy to fix).

@DanBurton While I don't have any use for Stackage myself mostly because I don't use Stack either it doesn't mean that users of my packages don't sometimes ask for my packages to be included in order to reduce the unpleasentness of using Stack. I actually tagged the "help wanted" label 2 weeks ago already which seems to have gone unnoticed; i.e. I don't mind my packages which I release to Hackage being picked up by the Stackage downstream distribution, just as I don't mind them being included in Debian, Ubuntu, Fedora, Arch, Nix, etc.. I just expect Stackage to behave passively like all the other downstream distributions and not impose undue additional requirements beyond being a proper Cabal package released on Hackage and consequently adhering to the Hackage guidelines.

DanBurton commented 5 years ago

Understood, thanks for the explanation, @hvr.

For this case, and in the future, I would say you are welcome to close "add to stackage" issues like this as "a downstream concern", with a suggestion to open an issue on commercialhaskell/stackage instead. We're happy to track it on our end if you'd rather not be involved in getting your stuff onto stackage.

In this particular case, the PR by @2mol is sufficient and we'll work w/ them there on how to proceed.