Hi

[hdgarrood]

I have been thinking about a purescript package registry too - do you want to compare notes? I'd be interested to see how much our ideas of what the goals of a package registry should be line up.

[kritzcreek]

Hi, sure :) This is what I've been using as a guideline for now:

* PS Package Archive

** Minimal viable product

*** TODO Hosts Manifest files for PureScript packages
*** TODO Hosts content hashes for each package version
*** TODO Hosts a complete index
*** TODO Authenticates Package owners via Basic Auth
*** TODO Allows uploading packages/versions

** Nice to have
*** TODO Host package sources
*** TODO Diffs APIs and upholds SemVer for API level changes
*** TODO Build jobs (like hackage matrix)

** Open Questions
- SemVer the only versioning scheme?
- We need to design a new manifest file (definitely needs the compiler version eg.)
- Allow Github OAUTH as an alternative Auth?
- How to get a certificate? (Let's encrypt seems to be the way forward)

[hdgarrood]

So the stuff that's most important to me is what I wrote in purescript/psc-package#24. In my mind the main three goals of a package registry would be the three things listed there: a way of getting people to agree what package a given package name "purescript-whatever" refers to, a way of storing information alongside packages which everyone agrees on, and availability/integrity i.e. reliably obtaining package contents, even if an important library author has their GitHub account hacked (for example). If a registry doesn't provide those three things, and given that there are already various working(ish) package management options, I'm not sure that the existing package managers will have sufficient reason to start using a new registry. Does that align with what you're thinking?

[kritzcreek]

I agree with all the three raised points.

One additional goal I have for this project is to provide the full package index . If we want to explore any kind of dependency solving we need a datastructure which contains all the dependencies at each version of a package.

[hdgarrood]

Great :) yes, that's definitely something I think should exist too.

The next thing I was thinking was, for storage and retrieval of packages, I don't think a straightforward web service hosted by us in the style of try purescript or pursuit would work. If we had a situation where installing dependencies on a new project involved downloading a bunch of .tar.gz files from the purescript community server, I think it would be likely that we'd have problems like exceeding outbound data limits or just the thing going down and none of us being able to address it quickly. In that case, people would start losing trust and switching back to grabbing things from github.

I've been playing around with IPFS and it seems perfect; the only thing that makes me slightly hesitant is that they describe it as alpha-quality, but honestly I doubt we'd ever be able to match an IPFS-based system in terms of availability and reliability. It's only the very core function of IPFS that we'd be using, as well, so that part is the least likely to break.

[kritzcreek]

I listed hosting the package sources as nice to have because of the exact reasons you mentioned. As long as we serve as a source of truth, and provide content hashes it shouldn't matter from where the package gets downloaded. One problem I anticipate with this approach is what counts as the "content" we're hashing, because that would require the manifest to contain exactly what files belong into a package.

IPFS looks like fascinating technology. I think input from people running other package archives will be valuable and I consider hosting package sources as out-of-scope for now.

[hdgarrood]

I think it does matter where the package gets downloaded from: if we thought we could get a package from a particular URL, and we GET that URL but the thing we receive turns out to have a different hash, we haven't solved the availability problem — all the package manager can do in that case is fail with a hash mismatch error.

[hdgarrood]

Incidentally there is a package manager based on IPFS already called gx, and the main ipfs implementation, which I think is called go-ipfs, uses it. There's a fair bit of discussion in both Nix and ArchLinux about using it too, although I don't think that's gotten anywhere significant yet. Dhall makes a lot of use of it in a sort of package archive sense as well.