[Haskell-cafe] SLURP: a single unified registry for Haskell packages

[Bram Neijt]

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 at example.com"}

Greetings,

Bram

On Mon, Jan 22, 2018 at 1:44 PM, Simon Peyton Jones via Haskell-Cafe
<haskell-cafe at haskell.org> 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.