Thomas Honeyman

There is some potential overlap with the optional “owners” field, though that requires a public key if I remember correctly.

Looks like this is a misleading error and the real culprit is that the package has been deleted. I am traveling but can look into it soon — in the...

I like this idea. A couple extra points: > The registry pipeline is the sole publisher to Pursuit nowadays. It seems unnecessary to support additional authentication workflows in Pursuit. This...

I’m all for keeping historical docs around if it’s trivial to do so; but I would personally be OK dropping old package docs if not. The source code still exists...

> What we actually store for docs in the registry I think it's OK to duplicate information into the `docs.json` for a package since this is an artifact of compilation...

I’m on board with that. It should be no trouble for all packages which can be compiled; I’m less confident about “historical” docs, i.e. those in pursuit-backups which may not...

Yeah, that's a hard question. We currently support either GitHub or an arbitrary Git web location as package sources: https://github.com/purescript/registry-dev/blob/772586e133089a06483ddafb9ff15a654e0c6007/lib/src/Location.purs#L25-L29 For something like a GitHub monorepo we can follow the...

The registry doesn’t know or care about tags; it all is based on the Publish payload you send, which must specify the version. A monorepo package is therefore the same...

Yeah, no strict git tag requirement, though if you publish a git package you do provide a ref: https://github.com/purescript/registry-dev/blob/772586e133089a06483ddafb9ff15a654e0c6007/lib/src/Operation.purs#L76 It _feels_ like not a huge lift to do a hosted...

I should really just take that out of the library altogether, as a better alternative has come out: https://github.com/jeslie0/mkSpagoDerivation