List view
- No due date
This milestone tracks the works needed to achieve support for parametric libraries in dune, as per the design described in [Parameterized Libraries in Dune](https://docs.google.com/document/d/1Lrlu7doqe_fOmIcNorf2PzMGL1gAKFiEDUSE7MI782U/edit?usp=sharing)
Overdue by 24 day(s)•Due by November 17, 2025•10/12 issues closed- Overdue by 2 month(s)•Due by September 30, 2025•2/3 issues closed
We are aiming to achieve a "Minimal Stable Product" (MSP) for `dune pkg`. We take MSP to mean: 1. That `dune pkg` can be used reliably by OCaml users for developing *most* OCaml software projects. 2. That users do not need to make recourse to `opam` or other package management systems, *unless the workflows requiring workarounds are identified and documented*. **Developing OCaml software projects** includes more that just building projects and installing their dependencies. It also includes, at least: - being able to install any desired OCaml developer tools - being able to query packages available for installation - being able to install software from the ecosystem that is commonly used in development - publishing packages developed using `dune pkg` - generating projects preconfigured to work with `dune pkg` - launching repls - interoperating easily with common IDEs (VSCode, Vim, & Emacs) - running tests - generating documentation When we determine that this milestone is achieved we will record this outcome by removing the "experimental" warnings on the online and CLI documentation for `dune pkg`, and we will then begin encouraging working OCaml developers to use `dune pkg` in their day to day work. - This stage of the tools should be *stable* in the sense that it works reliably, and supports the essential, day-to-day activities of individual developers and small software teams. - This stage of the tool is *minimal* in that we don't need to solve every problem or provide all the planned features. For example: - We don't need to solve portable, shared locking based on a checked-in lock directory to ship the MSP, since most ocaml users don't currently use this in their projects, and we achieve most of what we need for locking by pinning the opam-repo. - We don't need to provide flashy terminal output: while nice terminal UX is a nice to have and will be supplied eventually, that is completely inessential for a working alternative to opam. - We don't need every sub-feature to be fully stable: we can "demote" the "experimental" warnings to other parts of the tool (such as the `tools` sub command), when we still feel like we need to warn users about instability or likely breaking changes. - We don't need to discover or fix every bug users are likely to encounter: we should expect, and indeed we want, real users to report the problems they encounter while trying to use `dune pkg` on real projects (after the MSP is completed).
Due by March 31, 2026•26/38 issues closed- No due date•2/12 issues closed