Accept multiple package manifest formats

[thomashoneyman]

The registry by default only accepts a purs.json manifest file.

However, we've demonstrated in the legacy import tool that it is possible to derive a purs.json manifest from a legacy Spago manifest file — though it means creating version ranges from thin air. This got me thinking.

If a manifest file format is in use in the community, and it can be used to derive a correct purs.json manifest without having to modify the user-provided data, then I suggest we support it directly in the registry. This gives users fewer files to maintain in their repositories and less duplicated data. For example:

1. The registry always accepts purs.json files, and any package manager can support the registry by generating this file on behalf of their users.
2. If a package has no purs.json file, then the registry will fall back to the first supported format it finds. For example, the new-style Spago config files will have a format usable for a purs.json file, so a package with a spago.dhall file using the new format will be accepted.
3. If a package has no supported manifest files then it will be rejected.

In order for a format to be supported it must be translatable to a purs.json schema with no modifications. For example, that means:

1. It must have a way to derive all required fields in the schema, including version ranges
2. It must provide its users a way to use any optional fields that could end up in the purs.json (it shouldn't omit fields such as the "owners" field)

To start we would only support the spago config format, with the option to expand over time if we want.

[JordanMartinez]

Template Haskell is something that is used to eliminate a lot of boilerplate, but it can often feel too "magical" so that one doesn't understand what's going on behind the scenes. Could a similar issue occur here?

[thomashoneyman]

This is different. It’s more like the purs.json file is a standard. You can implement a config for your package manager, and if that config contains everything required by the purs.json standard then you don’t have to generate it as an additional file. There’s no code involved.

[f-f]

This is really a social issue: we meant to disallow publishing through the legacy pipeline at some point, as that doesn't give us a channel to report publishing issues to package maintainers.
This means that every package published from that point on has to have a purs.json. How would this transition to another config look like? Would it mean that people would have to implement support here, and only then start publishing with the new format?

[thomashoneyman]

Just to clarify a little: I am only suggesting that we omit the requirement to have a purs.json file IF your project uses another configuration format that the registry explicitly supports. Mostly, I'm thinking here of Spago: if your Spago file is 100% compatible with a purs.json file, then we could let you omit the purs.json file rather than generate and commit it.

However, this is just omitting the purs.json file when submitting your package to the registry. The purs.json file is still the lingua franca for all packages as far as the registry is concerned:

• The registry will generate a purs.json file from your config file if there isn't one in your repo already
• The compiler still only accepts purs.json files for publishing
• Package managers are guaranteed that a purs.json file will exist in the packages they download, so they can interoperate with the registry regardless of what package manager was used to upload the package

[thomashoneyman]

#593 implemented support for spago.yaml files. We can support more config files in the future if we want, but spago.yaml is all that's planned for now so I'm going to close this.