-
Notifications
You must be signed in to change notification settings - Fork 8
Description
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
- Allow using
- 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
- Snapshot version scheme. This is a bit of a tangent and not a hard requirement according to Repology's docs, but they have a proposed scheme for naming snapshot versions ([discussion] unified scheme for snapshot versions repology/repology-updater#345). If we ever add support for snapshot versions in Brioche, we should look into this.