Thank you for your insights, @Kakadu.
It is not obvious for me how to release in opam shrinked versions of libraries without conflicts (using the broad meaning of the word conflict)
I share your uncertainty. I’ve been using a custom opam-repository to manage my packages. This setup includes automated releases and works well with inter-project dependencies on GitHub CI. I’m very thankful for all the tools that I’ve been able to leverage there (opam, dune, dune-release, setup-ocaml, etc).
However, I’ve hesitated to publish to opam due to a few concerns:
-
My projects are mostly personal (educational, experiments, etc.), and I don’t expect them to be of broad interest.
-
I’m conscious of the opam-repository maintainers’ time and wouldn’t want to burden them with PRs for projects with limited use.
-
I’m concerned about potential namespace conflicts, which isn’t helped by the fact that I would prefer using literal naming schemes.
I find @yawaramin’s proposal for an opam namespace quite appealing, as it would address my concerns, but it’s from 2020 and I don’t know enough about the current ecosystem.
Community backing for a project can also help alleviate these concerns, as it provides a sense of shared ownership and responsibility.
I’m eagerly awaiting the dune pkg MVP. I hope it will provide further clarity on how I could best use opam/dune to share my work comfortably.