In the java ecosystem the popular maven package manager has two main repositories: maven core, which like the main opam repository requires libraries to be approved by someone to get in, and jitpack, which anyone can upload anything to with no vetting. There’s definitely value in having a vetted and more trustworthy main repository, but there’s also value in having a more freewheeling repository for libraries that don’t meet the standards for the main repo or where the author can’t be bothered to submit it. Is this something other people would want as well?
Hello, I think esy almosts answers that need. Esy allows you to use to use npm as a package repository, and npm doesn’t require any vetting !
However, any project that depends on a npm-published library needs to use esy, since opam can’t import from there. So there’s a tradeoff (but I think such tradeoff would also kinda be there with a jitpack equivalent).
It would quite simple to create an opam-compatible unmanaged repository and add it in parallel to the official one. See for example the janestreet and xs-opam repositories as independently managed ones.
The only downside I see is that when something goes wrong most people will come to complain on the official opam repository, further stretching our limited resources.
1 Like
I’m a bit curious in what you think the opam repository is asking too much from your packages ?
There’s no real standard to be met to be included in the official repository except for your package to be buildable on the platforms it claims to be buildable on. That seems the minimum for anything to be useful.
2 Likes
opam pins also allows users to refer to packages outside of repositories. So an formal packages repository isn’t required to share temporary or in-development packages with other users.
EDIT: Sorry @mseri - I know you’re aware of this! I didn’t mean to reply directly to your comment.
1 Like
Mostly unrelated to the thread topic, sorry, but FWIW, there have been a couple times where I was annoyed by the time and aggravation needed to make the opam CI happy due to e.g. ridiculous distros like alpine failing to build the package.
As a publisher I do also sometimes get annoyed by the slow CI but OTOH as an opam repository user I’m very glad things do not explode in my face every time I try to install and upgrade packages. For that there’s little you can do except testing before stuff gets in.
I mean if the OP’s idea is that you would like to be able to distribute stuff without caring for the end-user experience (“it works on my machine”) then pins as @hcarty mentioned or making your own repo seems entirely sufficient.
1 Like