Lately I’ve been working on reducing dependency footprints in some of my projects, which led me to repackage some of Jane Street’s libraries that I frequently use. The goal was to make these libraries depend solely on Base, thereby making them more accessible and lightweight.
These libraries required minimal modifications to remove the original dependencies from Core, Core_kernel, or Core_extended, depending on the case.
For instance, the Nonempty List library is a repackaged version of Core_kernel’s Nonempty_list. The original code can be found here. I’ve modified the code slightly to remove dependencies on Core and Core_kernel, making it solely dependent on Base. This allows the library to be used in more contexts without the need to add a dependency on Core and Core_kernel.
I’m reaching out to gauge interest in these repackaged libraries. While the use case might be niche, I believe there could be Base users who are motivated enough to limit their dependencies on core, etc.
If there’s interest in the community for these libraries, I’m considering reaching out to Jane Street to discuss options. If Jane Street isn’t interested but the community is, I’m open to moving these libraries into a community space. I’m also willing to volunteer as a maintainer in this case. Of course, I want to respect the community’s established practices and wouldn’t want to step on anyone’s toes.
If there’s no interest, I’m happy to continue as is. I’m simply offering this in case it might be beneficial to others.
I appreciate your time and look forward to your feedback!
I have spent some time on something similar too. My goal was to shrink the size of the rewriter executables. The motivation was to shrink that size of the dune _build directory when we actively developing new rewriter (we get excessive copies of intermediate rewriters)
It looks like that fattest dependency is ppxlib and removing base doesn’t give too much
This lib uses old version of dune (I think, to support internal integration of custom jenga tool or something). So, calling dune test is currently broken
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)
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.