WIP INTERNAL TO OCAML PLATFORM TEAM - DO NOT SHARE
Welcome to the twelfth edition of the OCaml Platform newsletter!
In this June 2024 edition, we are excited to bring you the latest on the OCaml Platform, continuing our tradition of highlighting recent developments as seen in previous editions. To understand the direction we're headed, especially regarding development workflows and user experience improvements, check out our roadmap.
Highlights:
Releases:
Contributed by: @rgrinberg (Tarides), @Leonidas-from-XIV (Tarides), @gridbugs (Tarides), @Alizter
Why: Unify OCaml tooling under a single command line for all development workflows. This addresses one of the most important pain points reported by the community.
What: Prototyping the integration of package management into Dune using opam as a library. We're introducing a dune pkg lock
command to generate a lock file and enhancing dune build
to handle dependencies in the lock file. More details in the Dune RFC.
Summary:
In last month's newsletter, we announced the Dune Developer Preview program, which marked our transitioning from prototyping Dune package management to user testing in preparation to a public release. We are now focusing on iterating based on feedback, aiming to develop a robust version of Dune package management that's suitable for widespread use in OCaml projects.
Based on our initial user interviews, this month included the following improvements:
dune-project
(particularly useful with Dune watch mode)dune fmt
. We're particularly excited about this feature and plan to extend this workflow to other Platform tools used by Dune.We've also begun upstreaming some of the features developed during the Developer Preview to Dune's main branch.
Activities:
Contributed by: @rjbou (OCamlPro), @kit-ty-kate (Ahrefs), @dra27 (Tarides), @AltGr (OCamlPro)
Why: Enhance OCaml's viability on Windows by integrating native opam and opam-repository
support, fostering a larger community, and more Windows-friendly packages.
What: Releasing opam 2.2 with native Windows support, making the official opam-repository
usable on Windows platforms.
Summary:
Opam 2.2 was released and announced on Discuss. The release comes with native support both for the opam client itself, and also for the compiler's packages in opam-repository
!
The community has already started rallying to make the opam-repository
more usable on Windows, including adding a CI check for Windows compilation on package submission (by @kit-y-kate at opam-repository#26069. They also started upstreaming opam-repository-mingw
patches for core packages, like OCamlBuild (by @hhugo at opam-repository#26164.
The GitHub Action ocaml/setup-ocaml
version 3.0.0 now uses opam 2.2.0 to bring OCaml support, and is ready to use in your GitHub projects (by @smorimoto). It's already in use in core projects, like Dune.
This release marks the end of the project, but the effort to create a delightful user experience for Windows users is far from being over! Now that the foundational building blocks support Windows, we as a community need to rally to make as much of the opam-repository packages Windows-compatible as possible. If you're a package author, we strongly encourage you to setup a Windows CI for your project and start addressing Windows-related issues on your packages.
Activities:
opam init
on Windows โ ocaml/opam#5991, ocaml/opam#5992, ocaml/opam#5993, ocaml/opam#5994, ocaml/opam#5995, ocaml/opam#5996, ocaml/opam#5997, ocaml/opam#5998, ocaml/opam#6000opam init -yn
to handle menus in the release candidate โ ocaml/opam#6033setup-ocaml
and depexts โ ocaml/opam#6046opam-repository
Windows CI โ ocaml/opam-repository#26081, ocaml/opam-repository#26073, ocaml/opam-repository#26080odoc
] odoc
3.0: Unify OCaml.org and Local Package Documentation (W25)Contributed by: @jonludlam (Tarides), @julow (Tarides), @panglesd (Tarides), @EmileTrotignon (Tarides), Luke Maurer (Jane Street)
Why: Improving local documentation generation workflow will help package authors write better documentation for their packages, and consolidating the different odoc
documentation generators will help make continuous improvements to odoc
available to a larger audience.
What: We will create conventions that drivers must follow to ensure that their output will be functional. Once established, we will update the Dune rules to follow these rules, access new odoc
features (e.g., source rendering), and provide similar functionalities to docs.ocaml.org (a navigational sidebar, for instance). This will effectively make Dune usable to generate OCaml.org package documentation.
Summary:
With the RFCs for odoc
3.0 completed and shared with contributors and the community for feedback, the odoc
team is transitioning from planning to implementation of the designs and features outlined in the RFCs.
This month's progress includes:
odoc
CLI to begin the implementation of the odoc
3 CLIIn the coming weeks, the team will continue this work, but it will also start looking into integration points with odoc
3.0, including Dune rules and integration with the OCaml.org documentation pipeline.
Activities:
path-references
to pages and modules: ocaml/odoc#1142path-references
lookup functionality โ ocaml/odoc#1150--current-package
option โ ocaml/odoc#1151Contributed by: @vds (Tarides)
Why: Enhance code navigation and refactoring for developers by providing project-wide reference editor features, aligning OCaml with the editor experience found in other languages.
What: Introducing ocamlmerlin server occurrences
and LSP textDocument/references
support for project-wide queries. This required indexing projects with local indexation using Shapes done in the compiler, a Dune-orchestrated global indexation, and the integration of these features in Dune, Merlin, and OCaml LSP.
Summary:
As announced a few weeks ago, Merlin project-wide references is now available in Merlin 5.1 and the preview of OCaml LSP 1.18.0. Users of LSP-powered editors (like VSCode with the OCaml Platform extension) and classic Emacs and Vim plugins can now query project-wide references of OCaml terms. This requires building the index with the new Dune alias @ocaml-index
.
This release represents the culmination of a multiyear effort by the Merlin team, including extensive work on the compiler to provide the necessary information for implementing this feature in Merlin.
We're beyond excited to share this feature with the community and look forward to your feedback.
While the feature should work well in most cases, we're aware of some limitations. Our next steps include adding support for interface files and module paths. Stay tuned!
Activities:
Merlin.5.1-502
, ocaml-index.1.0
, and a new preview of ocaml-lsp-server
with project-wide occurrences support โ ocaml/opam-repository#26114Contributed by: @xvw (Tarides), @vds (Tarides)
Why: Merlin and OCaml LSP currently offer different feature sets, creating inconsistencies in editor support. By achieving feature parity between the two, we aim to make OCaml LSP the comprehensive backend for OCaml editor support. This will provide users with a more consistent, feature-rich development experience across all editors, including Emacs and Vim.
What: We are upstreaming features from OCaml LSP, such as the signatureHelp
request, and ensuring we expose every Merlin feature from OCaml LSP, either through requests or custom code actions, such as type-enclosing
request.
Summary:
In June, we started work on bridging the gap between OCaml LSP and Merlin. We've started with exposing Merlin's type-enclosing request in OCaml LSP. The feature is now available as ocamllsp/typeEnclosing
.
As a reminder, Merlin's type-enclosing
feature allows users to get the type of the identifier under the cursor. It highlights the identifier and displays its type. Users can climb the typed tree to display the type of larger expressions surrounding the cursor.
Activities