Registry Alpha Launched

I’m proud to announce the beginning of the PureScript registry alpha! As of today the registry is live. Please see the linked README for details on what the registry is and how it works.

Note: As of today, you only need to interact with the registry when you register a package or if you want to submit a revision to the package sets. If neither applies to you, then the registry alpha does not affect you (directly).

Now that the registry is in alpha a few features have been turned on. Specifically:

  1. You can use the registry API to register or transfer packages and publish or unpublish package versions.
  2. Once your package is registered, then when you publish a SemVer Git tag to GitHub the registry will publish that version of your package. Publishing happens every day at midnight PST.
  3. When the registry publishes your package version it will also push your package documentation to Pursuit and attempt to update your package in the package sets. You no longer need to run pulp publish to publish docs or open a PR to the package-sets repo to add your package.

Now that package sets are automatically produced, we (the PureScript packaging team) are deprecating the package sets publishing process. This will happen on Wednesday, September 21. Nothing will change for package set users (ie. Spago users), but the process will change for authors. For all the details, please read the “Changes to the Package Sets” section below.

If you are not a package author, then this is all you need to know! If you are a package author, then read on for more details on how these changes affect you.

1. Changes to Package Registration

Previously, you could register your package by making a pull request to the new-packages.json file in the registry repo. This is now disabled. Instead, open an issue on the registry repo which contains the JSON payload for a package addition. Please see the Add a Package section of the README for details.

Right now the registry API is used via GitHub issues, as described in the README, but we will launch a server and the Spago alpha in the next few months. The Spago alpha will provide package manager integration with the registry. At that point you will simply run spago publish and the rest will happen behind the scenes.

2. Changes to the Package Sets

Previously, you could add or update your package in the package sets by changing the relevant Dhall file, regenerating the packages.json file, and submitting a pull request. No longer!

The registry now publishes new package sets every day, if any packages have been updated. The package set is published in the registry repo and mirrored to the legacy package-sets repo. If you would like to submit a change to the package sets – for example, to update the versions of several packages that did not work with the package set on the day of their release – then you should use the the package sets endpoint of the registry API. The link contains instructions on how to use the endpoint.

There is one more important change: the format of the package sets file has changed, because the registry now knows all the dependencies of your package. (If you’d like the full details on the new package sets, please see the package sets section of the spec.) This means the dependencies for your package in the package sets are taken from your Spago or Bower file. If you currently list dev dependencies in your Spago file, you should move them to a separate file.

And that’s it! Please enjoy the registry alpha, and if you have any issues, please describe them here in this thread or open an issue on the registry-dev repository. Thank you!



When does the day start for package updates? We often update 5-6 packages when hyrule gets updated, so that way I can roll out new versions several hours before the cron job kicks in.


Package updates happen either right away when you submit a new package version via the API, or nightly at midnight PST. Package set updates happen immediately after the package updates.

You can see the job here:

For example, I like to check the job the day after I publish a new package version just to make sure my packages were updated properly.


The legacy package sets publishing process has officially been deprecated! The package-sets repository no longer accepts issues or pull requests. Your package will automatically be added to the package sets (if possible) as part of the package publishing process. If you need to manually update the package sets, then please see the registry for instructions on using the batch package sets API.

The most recent package set is psc-0.15.4-20220921, which has been generated automatically by the registry. All package sets from now on will also be mirrored from the registry.

Please let us know if you encounter any issues. Thank you!

1 Like

Should the Issues and Pull Requests tabs be removed from the package-sets repo then?

Edit: Actually, I guess only the Issues tab can be removed.

We’re closing out the current issues and then we’ll remove the Issues tab and limit pull requests to collaborators only (unfortunately, we can’t disable them altogether, and we can only limit them for up to 6 months at a time :anguished:). If continued PRs become a problem then we’ll add a bot to close them automatically, but hopefully we don’t need to.

1 Like

Thankyou to all involved. The registry is/was a monumental effort! The future looks bright because of this work


Does this mean that I can delete the bower.json files from all of my packages now?

You can delete your bower.json file, but just be aware that the version bounds for your dependencies will be inferred from your spago.dhall + packages.dhall with the following rules:

  1. All dependencies must point to registered package versions (ie. you cannot point to arbitrary packages or branches like main).
  2. Dependency ranges will be produced from the exact versions in your package set + overrides according to the below rules. If you want more exact control over dependency ranges then you will need to have a purs.json file or a bower.json file specifying ranges:
    • 0.0.1 produces >=0.0.1 <0.0.2 (ie. an exact version)
    • 0.2.1 produces >=0.2.1 <0.3.0 (ie. next minor version)
    • 3.2.1 produces >=3.2.1 <4.0.0 (ie. next major version)