Tout est là:
https://zoggy.good-eris.net/posts/2026-03-16-own-opam-repo.html.fr
#ocaml
Here's a special little error. I'm wondering if my dune build isn't using what's on disk, but the checked in git code, and I'm getting an error:
`[NOTE] Ignoring uncommitted changes in /workspaces/haxe-compiler-dev/vendor/haxe (`--working-dir' not specified or specified with no
argument).`
Only, thing is, I've tried adding `--working-dir` but `dune` doesn't recognise it, and isn't telling me who it is that needs the argument.
Neither Google nor Bing are telling me anything.
fuck
edit (wait, nope, my bad)
Dear everyone, we just published an article on our #opam-repository archival work https://blog.robur.coop/articles/2025-03-26-opam-repository-archive.html
Happy reading #OCaml #opam #sustainability
I've had a machine with a default opam switch and a certain pin. I removed the pin and that triggered an update of the default switch to a new compiler version.
I have reservations about the idea to upgrade the compiler version without an explicit request from the user to do exactly that, but removing a pin really should do just that — remove a pin. The current behavior feels like a bug.
It is my pleasure to announce below the list of opam packages that will move to the opam-repository-archive on January 1st 2025. In total there are 4170 opam files scheduled for being moved within 561 unique packages. This decreases the size of the opam-repository by roughly 12.7%. This list contains all packages (a) marked as “available: false” (which may have various reasons: security issue, source unavailable, … - best to look into the “git log” for the specific package for the reason), and ...
there is no standalone #MirageOS file system (and many of our unikernels don't need one). So, in the case of opam-mirror, we use the ocaml-git memory implementation: Git_mem.
Git_mem is different in that #Git objects are simply stored in a Hashtbl. There is no cooperation point when it comes to obtaining Git objects from this Hashtbl. So let's return to our original advice:
don't wrap code in Lwt if it doesn't do I/O.
And, of course, Git_mem doesn't do I/O. It does, however, require the process to be able to work with Lwt. In this case, Git_mem wraps the results in Lwt as late as possible (as explained above, so as not to slow down our processes unnecessarily). The choice inevitably means that the right-hand side can no longer offer cooperation points. And this is where our problem begins: composition.
ocaml-git wants to be a low-level library for irmin. By this fact, high-level commands such as a (patience) diff, git status, etc. are not implemented.
As a MirageOS project, ocaml-git is system agnostic. However, it provides a git-unix package which uses UNIX syscall and is able to introspect a usual Git repository in a filesystem. However, ocaml-git handles only Git objects and does not populate your filesystem as git does. For example, Git_unix.Sync.fetch does not give you files fetched from the repository but only synchronizes .git with that repository
#opam
https://blog.robur.coop/articles/lwt_pause.html
https://github.com/mirage/ocaml-git/tree/a36c90404b149ab85f429439af8785bb1dde1bee