@hdgarrood thanks for the great post and for the kind words! 
In the past months I reflected on some things that you touched on, so I’ll do a bit of a brain dump on them here (I’ll write down some more context to help readers not involved with the details of this)
Version bounds
Premise: humans are not good at versioning, and bounds are accurate only if they are machine-checked (corollary: bounds that have not been machine-checked are fictional)
In JS and other dynamic languages you have to run the thing in order to machine-check, but having a nice type system and some care from humans (i.e. “breaking the types” on behaviour change) means that we can run a huge CI to compile together all the various combinations of packages to see if the human-inputted bounds make sense.
This is what the Hackage Matrix CI does, (here’s a random package from it), but not even in there they compile with the whole set of versions in the bound (i.e. one working plan per compiler version is enough)
This is basically what we do in package-sets too, except in our case it’s enough that there’s a build plan with the latest versions in the set.
In the end this means that I think the “package set” approach is equivalent to the “version bounds” one, except there’s combinatorially more CI involved in the latter (the assumption here is that humans are not supposed to select versions of packages to use. You have a single version available or a solver that picks it for you)
A PureScript package registry
I also agree that we should have a proper package registry and the current situation is less than ideal.
As @chexxor mentioned the fact that the Pursuit DB is disjoint from the Bower registry is sometimes uncomfortable, and I wrote down a proposal to avoid manual publishing of docs, and sync packages and releases from Bower instead (which is the “single source of truth” at the moment)
While Entropic sounds interesting, it currently looks like a self-hosted npm and this means that we’d still need to upload docs somewhere, and that somewhere would still need to be kept in sync.
I also think we shouldn’t try too hard to get packages on npm (or the next npm), as that would be convenient for the JS backend but not for the others (as they’d have to still use the whatever-VM package manager to get packages for that VM), so this means having a somehow-integrated PureScript-only registry.
Features I’d like for it:
- package uploads
- integrity checks for packages (i.e. hashing package contents)
- docs for packages
- storage for package sets
- should be distributed
This looks like a distributed Hackage+Stackage, and there are no existing registries that do this out of the box (though if you squint you can see that it is basically a Nix cache with some sugar on top, more on this below)
It looks like this idea has been considered in the making of Stack 2 too: in the Stack 2 announcement post you can read about a “Pantry server” which would be a distributed content-addressable storage server (it probably makes more sense if you also read all the Pantry articles linked from the above post. For context, “Pantry” is the part of Stack that fetches stuff)
In the end I think implementing something would not be a big effort: such a backend can be put together with a git repo (for holding the metadata, hashes, checksums, etc) and an S3 bucket (to hold the package uploads and generated files).
Advantages of doing this (note that this is basically nixpkgs: git repo + huge CI):
- not necessary to implement authentication, as packages would be added as PRs (so we’d exploit authentication implemented in GitHub/GitLab/$GitProvider)
- the git repo itself is easily mirrored on GitHub/GitLab/self-hosted so availability is guaranteed if clients implement fallback logic in case of unavailability
- the file storage is easily distributed since since mirroring an S3 bucket somewhere else is trivial
- everything is just static files and there’s no actual HTTP backend running, so yay less security holes
@hdgarrood if any of this makes sense I can put together a small prototype