[Draft] Specification of the dune tools implementation - #15543
Draft
shonfeder wants to merge 72 commits into
Draft
[Draft] Specification of the dune tools implementation#15543shonfeder wants to merge 72 commits into
shonfeder wants to merge 72 commits into
Conversation
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Ali Caglayan <alizter@gmail.com>
Let's add this back when the document takes shape to clarify confusion. At the moment it is not adding anything and is potentially confusing. Signed-off-by: Ali Caglayan <alizter@gmail.com>
Signed-off-by: Ali Caglayan <alizter@gmail.com>
Signed-off-by: Ali Caglayan <alizter@gmail.com>
- It shouldn't mention implementation details (switch etc.) - It is too constrained (excluding tools defined in a project build) - Given unnecessary context (mentioning current design) - Does not include wide enough examples of tools (only mentions tools we widely used and already supported with bespoke mechanisms) Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
This is essential for clear communication, otherwise key terms get used inconsistently or understood ambiguously. As a result of recovering terminology we also detect an error in the "generality" principle: packages themselves are not tools, but they provide tools so "any opam package ... can be a tool" is a category mistake. Signed-off-by: Shon Feder <shon.feder@gmail.com>
This is not a useful section: things that aren't required just don't need to be listed as requirements. The canonical way of differentiating necessary from merely recommended requirements is MUST vs. SHOULD (or RECOMMENDED): https://www.ietf.org/rfc/rfc2119.txt Signed-off-by: Shon Feder <shon.feder@gmail.com>
If we are going to have a section of principles, let's make them principled principles. - "Clean source tree" is a requirement or an implementation detail - "Orthogonality" as stated was an implementation detail, generalizing it gives a principle. - "Multi-version" looks like a requirement, and it is entailed by a the principle of orthogonality Signed-off-by: Shon Feder <shon.feder@gmail.com>
- Drop implementation details from definition of "install" - Redefine "available" in terms of "install" as "installable" Signed-off-by: Shon Feder <shon.feder@gmail.com>
- Everything but summary after TOC - "how to read doc" sections should be first Signed-off-by: Shon Feder <shon.feder@gmail.com>
- May as well link the sections. - Explain what the terminology section is for. - Remove CR explanation: no place for those in the mergable doc. Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Make it clear that, while compatability is required, satisfaction is not. Signed-off-by: Shon Feder <shon.feder@gmail.com>
Reference to legacy system is not relevant for requirements (could be in implementation) Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
These are design ideas for possible functionality, they are not relevant to functional specifications. Signed-off-by: Shon Feder <shon.feder@gmail.com>
But make this a "SHOULD" rather than a "MUST" Signed-off-by: Shon Feder <shon.feder@gmail.com>
Since packages provide tools, rather than define them, we avoid equivocating between package names and tools: a package may provide a tool that shares the package name, but when tools are invoked, it is done by the name of tool executable, not by the name of the package. Therefore, binary selection is just the ability to filter a subset of available packages in case you don't want everything provided by a package (the default). Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
No idea why this was merged alongside an unrelated requirement. Factor the versions pecification requirement into its own issue. Signed-off-by: Shon Feder <shon.feder@gmail.com>
Not sure why this overspecification and reduction in generality. We want the general usability. Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Many of there are out of date, e.g., work on in-and-out is onging, and we have settled in conversation that support for something like an `env` subcommand is required (most recently in the metting with the team working on editors). There is also no reason to rule out precompiled binaries or ephemeral runs: if we don't state those as requirments now, we won't work on implementing them at this point. There is no reason in principle such things shouldn't be considered in the future. Signed-off-by: Shon Feder <shon.feder@gmail.com>
It is important to be able to consider the requirements above the code level and without commitment to specific implementation details. Splitting the implementation spec notes into their own file help support this abstraction. Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
These are implementation details, and are covered on the requirements side by "programmatic use" Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Entailed by principle Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Relevant parts extracted from issues on the issue tracker tagged 'dev-tools' Signed-off-by: Sudha Parimala <sudharg247@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Links aren't rendered in summary tags, and we will have additional details we want to add probably, so let's make the collapsed section more general. Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
It didn't make sense in the req it was under, and indeed we didn't have a req for it. Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
Signed-off-by: Shon Feder <shon.feder@gmail.com>
To be added back in a new branch, and staged as its own PR. Signed-off-by: Shon Feder <shon.feder@gmail.com>
This reverts commit 3ec903e.
Sudha247
reviewed
Jul 23, 2026
| dune tools list List all locked tools and versions | ||
|
|
||
| dune tools add Lock all tools from (tool) stanzas | ||
| dune tools add <pkg>[.<version>] ... Lock specific tool(s) |
Member
There was a problem hiding this comment.
Does this require the tool that's being added to have a tool stanza in the workspace?
Signed-off-by: Sudha Parimala <sudharg247@gmail.com>
This is a rewrite of the tool stanza with the following: - Include relevant fields from lock_dir stanza. - Introduce a special variable :inhert, and a field (inherit_lock_dir) to inherit config from lock_dir stanza. - More examplesWq Signed-off-by: Sudha Parimala <sudharg247@gmail.com>
Signed-off-by: Sudha Parimala <sudharg247@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR proposes the (WIP) implementation specification split off from #13457 , developed initially by @Alizter and to be refined, extended, and revised in the ongoing discovery work towards a solid implementation design.
Related Issue and Motivation
Fixes #15544
Checklist