[draft] Tool management requirements

[shonfeder]

This proposes a set of high level, functional requirements for our tooling management functionality.

Fixes #15545

The requirements proposed here are informed by our experience with the current prototype, our use of other successful tools addressing this problem space, and by recent design discussions.

• This should be informed by (and make reference to) existing successful package management tools (uv, cargo, etc.)
• This should be informed by (and make reference to) what we have learned from the shortcoming of the current implementation

[Alizter]

@shonfeder I've gone through my own design notes and prototype to update this document. As it stands it is still a WIP however there is much more material that can be fleshed out and discussed. I've split the requirements into functional requirements and a technical specification, although it isn't perfect. I included my own research on similar features from other package managers, but this could be expanded further. Hopefully this closes the gap between what we dissected and what I had in the prototype.

The CRs should answer most questions you have reading the docs, but further changes and additions/deletions are welcome.

The end-goal will be to address all the CRs so they are not a permanent feature.

[Sudha247]

Thanks for writing this down, this is very useful. I read through parts of the document and some comments below. Will do another pass later.

[Sudha247]

Any downsides to automatically locking and installing when the tool is not found?

[Leonidas-from-XIV]

The problem is that in that case the command that would launch the dev tool locks up for an extended time period with no good way to communicate to the caller that it's locking, downloading and building the dev tool.

It might still be worthwhile but its good to have this issue in mind when designing.

[Leonidas-from-XIV]

Thanks for pushing this along. It's one of the most important things in package management (arguably even the most) and I appreciate that this is starting to move along.

[Leonidas-from-XIV]

"work tree" is probably the better wording here.

[Leonidas-from-XIV]

The problem is that in that case the command that would launch the dev tool locks up for an extended time period with no good way to communicate to the caller that it's locking, downloading and building the dev tool.

It might still be worthwhile but its good to have this issue in mind when designing.

[Sudha247]

Another option could be to provide a warning that the tools are not built while returning the path. However, I'd imagine consumers of this could be other platform tools. In that case wouldn't having a hard error break their workflows?

[Sudha247]

It's good to see this moving along! I'm of the belief that this is one of the most important, if not the most important, features for Dune package management. Thanks for pushing this along @Alizter and @shonfeder.

I'm generally happy with the direction this is moving along. However, I think we still have some open questions to address before we can merge this.

[Sudha247]

I want to make a note here that this differs from the auto-locking model we have been discussing in #13011. It could be the case that the two of them have different needs and hence different models. However, it's worth documenting why that is. Both of them share several similar concerns:

• It was stated in the quoted issue that users find it tedious to maintain lockfiles. Even though there is no explicit lock file visible to the user, that concern still applies here.
• Why is the model for deps to update by default when we run dune build, and not the case for tools?
• This model also makes offline mode a possibility, which is still an open problem for dependencies.

[Sudha247]

This example is perhaps not in line with 6.5, which states that tools are always built from source.

[Sudha247]

This needs a pass before merging.