The current design of the dev tooling feature is provided thru the dune tools subcommand. We seem to have widespread consensus among the devs active on package management that the current status quo is not sufficient.
Reworking will require substantial redesign, but at minimum we must fix the many errors and shortcomings that leave dune package management without an adequate way to manage development environments w/r/t tooling.
Current known defects and limitations include the following:
- The development tools are currently a hard-coded list. Each tool is added manually thus it requires a Dune release to add a tool.
- Due to that, the tools have a complex set of tests that are verbose and tool-specific
- The configuration does not respect with the
with-dev-setup functionality of OPAM dependency specifications
- Configuration of the solver for dev tools is unintuitive and requires knowledge of Dune internals (e.g. where lock directories are stored) that should not be required for this task
- The UX is still rudimentary (e.g., there is no way to install multiple tools in one command)
Tasks
Related issues
All the issues labeled dev-tools fall under the scope the needed rework:
Designs to consult and incorporate
The current design of the dev tooling feature is provided thru the
dune toolssubcommand. We seem to have widespread consensus among the devs active on package management that the current status quo is not sufficient.Reworking will require substantial redesign, but at minimum we must fix the many errors and shortcomings that leave dune package management without an adequate way to manage development environments w/r/t tooling.
Current known defects and limitations include the following:
with-dev-setupfunctionality of OPAM dependency specificationsTasks
Related issues
All the issues labeled
dev-toolsfall under the scope the needed rework:Designs to consult and incorporate