Great idea, I just have a few (3) questions that I would like to see clarified in the document: 1) I don't understand this URL: GET /package/:pkgname/preferred returns a JSON structure listing all versions Why is it not /package/:pkgname/versions to get a list of versions? What does preferred mean in this context? 2) Must the package URL end with .tar.gz? Stack supports plain tar and zip as well and if we start enforcing this, maybe tar.xz would be a better choice for a new system. 3) Would a contact or e-mail address not be a sensible thing to add to the registration PUT json? This would allow the SLURP trustees to contact somebody, e.g.: {"name": "mypackage", "location": "https://myserver.com/package/mypackage" , "author": "admin@example.com"} Greetings, Bram On Mon, Jan 22, 2018 at 1:44 PM, Simon Peyton Jones via Haskell-Cafe wrote:

Friends

Hackage has been extraordinarily successful as a single repository through which to share Haskell packages. It has supported the emergence of variety of tools to locate Haskell packages, build them and install them (cabal-install, Stack, Nix, ...). But in recent years there has been increasing friction over,

Hackage’s policies, especially concerning version bounds; Hackage's guarantees, especially around durability of package content and metadata; Hackage's features, especially the visual presentation and package documentation.

If we do not resolve this friction, it seems likely that the Haskell library ecosystem will soon “fork”, with two separate repositories, one optimised for Cabal and one for Stack. This would be extremely counter-productive for Haskell users.

Thus motivated, over the last few months we have talked a lot to colleagues, including ones in the Hackage and Stack communities. We have emerged with SLURP, a proposal that could go a long way towards supporting the upsides of a diverse ecosystem, without the sad downsides of forking into mutually-exclusive sub-communities.

Here is the SLURP proposal. We invite the Haskell community to debate it.

SLURP is meant to enable both Hackage and Stackage (and perhaps more services in the future) to in the future make choices autonomously without hurting other package services. But it will only work if the implementors of both Hackage and Stackage are willing to participate. We respect their autonomy in this matter, but we urge them to give this proposal serious consideration in the best interests of the community and Haskell's success. We have carefully designed SLURP to be as minimal and non-invasive as possible, so that it can be adopted without much trouble. Of course, we are open to debate about the specific details.

We do have an offer from someone willing to implement SLURP.

We also strongly urge members of the community to express clear views about the importance --- or otherwise --- of adopting something like SLURP. You are, after all, the community that GHC, Hackage, Stackage, Cabal, etc are designed to serve, so your views about what best meets your needs are critically important.

Mathieu Boespflug (@mboes) Manuel Chakravarty (@mchakravarty) Simon Marlow (@simonmar) Simon Peyton Jones (@simonpj) Alan Zimmerman (@alanz)

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.