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).