Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add to stackage #62

Open
nh2 opened this issue Jan 30, 2016 · 13 comments
Open

Add to stackage #62

nh2 opened this issue Jan 30, 2016 · 13 comments

Comments

@nh2
Copy link

nh2 commented Jan 30, 2016

Hey, would you mind adding this library to Stackage?

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

@2mol
Copy link
Contributor

2mol commented Dec 12, 2018

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
Copy link

rodrigosetti commented Dec 12, 2018

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

@2mol
Copy link
Contributor

2mol commented Dec 12, 2018

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

@hvr
Copy link
Collaborator

hvr commented Apr 9, 2019

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
Copy link
Contributor

2mol commented Apr 9, 2019

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: commercialhaskell/stackage#4471

@2mol
Copy link
Contributor

2mol commented Apr 9, 2019

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

@hvr
Copy link
Collaborator

hvr commented Apr 9, 2019

@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
Copy link
Contributor

2mol commented Apr 10, 2019

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
Copy link
Collaborator

hvr commented Apr 10, 2019

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
Copy link
Contributor

2mol commented Apr 10, 2019

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
Copy link

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
Copy link
Collaborator

hvr commented Apr 10, 2019

@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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants