Skip to content

Repology integration #368

@kylewlacy

Description

@kylewlacy

Repology is a project that monitors software packages across different packaging ecosystems. The value for software maintainers is to give users information on which versions they can get from which sources. I've seen it appear on multiple repos, so it seems like quite a lot of software maintainers like that idea!

It'd be nice to have Brioche Packages show up as a repository in Repology. Luckily, they have a list of requirements for new repositories. So, from our side, we can start working independently to meet their requirements. Once we do, then we can start the conversation to get an integration going between Repology and Brioche (...no clue what that process looks like though)

Status

(Loose bullet points based on Repology's requirement documentation)

  • Simple machine-readable metadata format for packages. We should probably have an easy way to query this from the registry, such an endpoint to grab all packages and versions as a single request.
  • Add required project metadata. We currently only have package name and version, but Repology also wants, at minimum, an upstream project URL and the recipe URL. The recipe URL we could handle by automatically linking to the appropriate commit+file on GitHub, but the upstream URL we'll need to handle explicitly. See also: Add support for more project metadata brioche#71
  • More packages. They don't have a hard limit on the number of packages, but they say this: "[...] we impose minimal requirements on maturity - that is, a repository should contain at least a few hundred packages and be maintained for at least half a year. "
  • Consistent package naming. All of our package names are short and machine-readable. The only caveat is we disallow -, instead only allowing _. I think this meets Repology's requirements.
    • Allow using - instead of _ in package names. We always use _ in package names for consistency, but I'd like to support both characters (with a restriction in the registry to disallow confusingly-similar names)
    • Figure out what to do about programming language packages. Repology calls out special rules here, although I'm not sure if we'll ever handle packaging, say, PyPI packages directly
  • Consistent version naming. Brioche is pretty loose on allowed version numbers, so we basically just adopt the upstream project version as-is. The plan in the future is to also support multiple simultaneous versions, see: Support packages with multiple simultaneous versions brioche#97

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions