ocaml
Opam package definition `dev-repo` field should allow multiple repository mirrors
dev-repo: <string>: the URL of the package's source repository, which may be useful for developers: not to be mistaken with the URL file, which points to the specific packaged version.— https://opam.ocaml.org/doc/Manual.html#opamfield-dev-repo
I believe Opam’s package definition should support this use case just as much as it does homepage: [ <string> ... ], doc: [ <string> ... ], bug-reports: [ <string> ... ]. Some projects use multiple mirrors without a concept of a canonical repository. This is great for future contributors that are banned/blocked by certain platforms (such as US sanctions blocking users from US-based platforms) or moral objections (such as not wishing to use proprietary code forges for participating in ‘free software’, but maintainers also wanting a hegemonic presence for marketing or whatever) or just to deal with the fact that uptime is always imperfect no matter the host / encouraging decentralization via self-hosting.
An OCaml-related example: Soupault
Soupault source code is available in two equally official locations:
- GitHub: PataphysicalSociety/soupault
- Codeberg: PataphysicalSociety/soupault
— https://soupault.app/contributing/
+1 to this request from me as well! I've personally been moving my code over to Tangled on Bluesky and would find it very useful to have multiple mirrors of my repos. I'm still intending to mirror the code on GitHub, just not make that the only place to get the code from.
I agree this seems like a nice feature, however sadly this is currently a syntax error so we would need to bump the opam syntax for this. Which means this is probably going to have to wait until opam 3.0 since this change wouldn't be backward compatible.
Now, instead, we could use an extension field: x-dev-repo-mirrors or something like that which would be ignored by previous versions of opam but used in newer ones. It's not the prettiest addition but it will work in a jiffy and work as a base for opam 3.0.
I'm personally ok waiting till opam 3 for this rather than forcing intermediate hacks. Although, I guess that any x- field could just be rewritten automatically into the "proper" field for opam-version: 3.0 when that happens, so it would be a good chance to test things out.