Skip to content

Accept multiple package manifest formats #435

Closed
@thomashoneyman

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions