[draft] Tool management design by shonfeder · Pull Request #13457 · ocaml/dune

shonfeder · 2026-01-26T03:33:07Z

This proposes a set of high level, functional requirements for our tooling management functionality, and contributes to #12914

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 · 2026-03-06T11:51:45Z

@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 · 2026-03-06T15:51:43Z

+
+CR-soon Alizter: Edge cases to specify:
+
+- Tool not locked: error with suggestion to run `dune tools add`?


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

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 · 2026-03-06T15:52:50Z

+- Specified version not locked: error with suggestion?
+- Build fails: propagate build error?
+
+#### 2.2. Programmatic use


Worth mentioning this should try to maintain as much backwards compatibility as possible to not break the workflows of other platform tools?

Do you have any particular tools in mind and how we might break their workflows?

For example, ocaml-lsp-server uses some dune tools .. commands, I believe.

Sudha247 · 2026-03-06T15:56:29Z

+- How does `path` interact with `(tool)` stanzas vs CLI-added tools? Same
+  resolution as `run`?
+
+CR-someday Alizter: Consider a single bin directory with symlinks to all tool


How would this work if there are multiple versions of the same tool locked?

Is this something we need to support? We should extend the spec with the requirement if so, but I'm not sure it's something we can or should consider as a requirement.

It needs to be discussed further I think. There are technical / usability benefits to doing so, but it also doesn't fit in well with our execution model otherwise.

Sudha247 · 2026-03-06T16:02:51Z

+don't need it (e.g., formatters that only parse source text).
+
+CR-soon Alizter: The utility of opting out seems debatable, but is part of the
+package-tool continuum approach.


package-tool continuum approach.

This sounds interesting. Can we read about this somewhere? More generally, I think both opt-in and opt-out come with their own set of caveats. But more tools require matching compilers than not, so it seems like a reasonable place to start.

It appears in it's own section below, I've linked it for you in another comment #13457 (comment)

Sudha247 · 2026-03-06T16:06:56Z

+- Remove tools
+- Discover paths to tool executables
+
+CLI-added tools persist until `dune clean` or `dune tools remove`, but are not


Do we need to remove the tools during dune clean? One might want to clean the project build without removing the tools. Does this also mean if one does rm -rf _build the tools will be gone?

Sudha247 · 2026-03-06T16:10:11Z

+
+#### 5.1. Format rules (`dune fmt`, `dune build @fmt`)
+
+`dune fmt` must use tools managed by `dune tools`. This includes respecting


Does this imply that ocamlformat installed via opam won't be used?

I think it should unless (pkg enabled) is set.

If dune tools add ocamlformat has not been done, then it will use the one from the switch. This is detailed in the PATH fallback requirement.

Sudha247 · 2026-03-06T16:14:24Z

+  ocamlformat to work for formatting your code. The standard tool isolation
+  handles this fine.
+
+- **Working on the tool itself** (e.g., developing ocamllsp): You likely want to


In-and-out is an issue, yes, but only for dogfooding in the same repo - for example, a developer working on ocamllsp would still be able to pin their local branch for other projects?

Yes, that would be achieved with pins.

Sudha247 · 2026-03-06T16:19:42Z

+#### Syntax
+
+```lisp
+(tool


Should we include a way to add dependency constraints for the tool?

Yes, those should be included.

shonfeder · 2026-03-10T02:59:10Z

+- How does `path` interact with `(tool)` stanzas vs CLI-added tools? Same
+  resolution as `run`?
+
+CR-someday Alizter: Consider a single bin directory with symlinks to all tool


Is this something we need to support? We should extend the spec with the requirement if so, but I'm not sure it's something we can or should consider as a requirement.

shonfeder · 2026-03-10T03:00:54Z

+
+The following are explicitly out of scope:
+
+#### 6.1. System-wide installation


I do not agree with this being a non-requirement. What is the motive for excluding this?

Counter-question: What is the motive for including this? I'm open to well thought out proposals, this is simply recording the requirements of the design I worked on and I didn't see a need for this yet.

We should also note that Dune even with package management is predominantly a build tool, not a package manager. Building dependencies makes sense because they are inevitable to get a project to be built but I don't think Dune has a reason to become a specialized package manager to install a subset of OCaml packages (those that build with Dune).

There's plenty of tools that do that already, including OPAM, which can also install non-Dune projects and would be better suited for this task.

@Alizter I detailed the motives here: #12107

We should also note that Dune even with package management is predominantly a build tool, not a package manager

Not if we are working towards the stated ocaml platform roadmap, in which case dune should become the frontend of the ocaml ecosystem.

If it will not become this, because we insist it should stay "predominantly a build tool" then we need a deep revision to the strategy we are working towards.

Note that this removes a requirement I had already specified in this doc, so putting the onus on my to justify why it should not be removed seems a bit backwards, IMO.

The OCaml Platform does state that Dune is intended to be the front-end of the OCaml ecosystem. If we decide to move away from this, it has to be clearly documented so as not to confuse users.

shonfeder · 2026-03-10T03:07:05Z

+#### 6.3. Tools for tools
+
+Using tools while developing the tools themselves (or their dependencies) has
+nuances related to the "in and out" problem ([#8652]).


I disagree with this being a non-requirement as well. The fact that there is an implementation problem making this infeasible to implement currently is not a good reason to explicitly exclude it from the requirements, IMO.

Whether or not it is a requirement should be based on whether it is feasible in principle and whether it is addresses legitimate user needs.

Given that your later remark seems to indicate that the need for this is well motivated, then this should be replaced as a requirement.

Note that it is not expected that all requirements will be satisfied in one fell swoop of implementation. Some may take some time to satisfy due to difficulty of implementation. In this case, the in-and-out problem is such a complication.

But this is exactly why the requirement must be included in the spec: stating it as an achievable aim (difficult tho it may be), based out our reasoning from essential needs and basic principles, helps us identify the dependencies between our different planned streams of work.

In addition to what Shon has said above, now that in-and-out is being actively worked on, this needs to be revisited.

Alizter · 2026-03-10T08:25:42Z

+project packages (the "wrapper package hack"), causing solver conflicts and
+complex regeneration logic.
+
+### The package-tool continuum


@Sudha247 Here is the section about the "package-tool continuum" idea.

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 · 2026-03-09T14:42:13Z

+**Why a new system?** The legacy dev-tools system only supported a hardcoded
+list of tools and required dune package management. The new system works with
+any opam package, whether you use dune's package management, an opam switch, or
+system OCaml.


Does that mean it does not require dune package management? How should it work in the absence of package management?

You don't require a lock file or package management to be enabled in order to use it. It does use package management behind the scenes but this is an implementation detail not exposed to the user. The idea is that dune tool will give the same experience for both dune pkg and opam users (or even just system ocaml).

I don't think this paragraph is needed here. It is covered in the issue that describes the motivation for the redesign: #12914

there we can just focus on optimal design itself, I think.

Leonidas-from-XIV · 2026-03-09T14:42:42Z

+
+- **Generality**: Any opam package providing executables can be a tool
+- **Orthogonality**: Tools are solved independently from project dependencies
+- **Clean source tree**: All tool artifacts live in `_build/`, not your repo


"work tree" is probably the better wording here.

Leonidas-from-XIV · 2026-04-01T08:51:53Z

+
+CR-soon Alizter: Edge cases to specify:
+
+- Tool not locked: error with suggestion to run `dune tools add`?


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 · 2026-04-01T08:58:17Z

+
+The following are explicitly out of scope:
+
+#### 6.1. System-wide installation


We should also note that Dune even with package management is predominantly a build tool, not a package manager. Building dependencies makes sense because they are inevitable to get a project to be built but I don't think Dune has a reason to become a specialized package manager to install a subset of OCaml packages (those that build with Dune).

There's plenty of tools that do that already, including OPAM, which can also install non-Dune projects and would be better suited for this task.

shonfeder · 2026-04-14T17:19:00Z

+**Why a new system?** The legacy dev-tools system only supported a hardcoded
+list of tools and required dune package management. The new system works with
+any opam package, whether you use dune's package management, an opam switch, or
+system OCaml.


Suggested change

**Why a new system?** The legacy dev-tools system only supported a hardcoded

list of tools and required dune package management. The new system works with

any opam package, whether you use dune's package management, an opam switch, or

system OCaml.

shonfeder · 2026-04-14T17:21:14Z

+- **Clean source tree**: All tool artifacts live in `_build/`, not your repo
+- **Multi-version**: Different projects can use different tool versions


These do not look like principles to me, they look like functional requirements?

shonfeder · 2026-04-14T17:24:36Z

+Any opam package that provides executables can be used as a tool. Unlike the
+legacy system, tools are not hardcoded into dune. Users can install arbitrary
+packages without waiting for dune releases.


We don't need to refer to opam packages again, because we have already defined tools as executables defined by opam.

Suggested change

Any opam package that provides executables can be used as a tool. Unlike the

legacy system, tools are not hardcoded into dune. Users can install arbitrary

packages without waiting for dune releases.

All available tools must be installable, without requiring changes to the dune

source code.

Best to focus the requirements on what is required. Mentioning things that don't work and aren't required in this kind of context just adds to complexity and verbiage, IMO.

shonfeder · 2026-04-14T17:27:56Z

+Tools are installed per-workspace, not globally. Each workspace has its own
+isolated tool installations that don't affect other workspaces or the system.
+
+See [Directory structure](#directory-structure) for storage locations.


This is an implementation detail, but the "how to read this doc" makes clear requirements aren't concerned with those.

shonfeder · 2026-04-14T17:32:52Z

+
+The following are explicitly out of scope:
+
+#### 6.1. System-wide installation


@Alizter I detailed the motives here: #12107

shonfeder · 2026-04-14T17:34:50Z

+
+The following are explicitly out of scope:
+
+#### 6.1. System-wide installation


We should also note that Dune even with package management is predominantly a build tool, not a package manager

Not if we are working towards the stated ocaml platform roadmap, in which case dune should become the frontend of the ocaml ecosystem.

If it will not become this, because we insist it should stay "predominantly a build tool" then we need a deep revision to the strategy we are working towards.

Adds reference docs for `dune tools` as stated in ocaml#14184. The implementation of dev tools is subject to change, as being discussed in ocaml#13457. But parts of the user facing commands might stay and we might want to update the docs as the implementation is being fleshed out. Signed-off-by: Sudha Parimala <sudharg247@gmail.com>

Adds reference docs for `dune tools` as stated in #14184. The implementation of dev tools is subject to change, as discussed in #13457. But parts of the user-facing commands might stay, and if we decide to merge this, we might want to update the docs as the implementation is being fleshed out.

Sudha247 · 2026-05-21T08:41:26Z

+
+See [Directory structure](#directory-structure) for storage locations.
+
+CR-soon Alizter: Once we have the relocatable compiler, tools being built will


Now that we have the relocatable compiler, should we update this?

Sudha247 · 2026-05-21T10:29:23Z

+can have different `.ocamlformat` files specifying different versions, and the
+formatting rules will use the correct version for each project.
+
+CR-someday Alizter: Multi-version scaling. Supporting N versions means N


Thinking more about this, do we really have other concrete use cases of having first-class support for multiple versions, other than ocamlformat? I do wonder whether this is introducing more complexity than solving user pain points.

One other use case is if the user wants to test out multiple versions of the same tool or test during development. The UI of dune tools run tool.version seems a bit unintuitive to me.

Which part is unintuitive exactly?

Markdown broke what I wrote, but I meant to say having to explicitly call tool.version if you have multiple versions seems unintuitive from the perspective of I want to run the tool.

It could be that this is fine for what needs to be done to support multiple versions, but I don't yet see concrete use cases other than ocamlformat.

Unless there are multiple versions of a tool around then there is no requirement to run dune tools run tool.version, just dune tools run tool will be enough. The case of ocamlformat is the main application as you've said, however how often is it that you want to run dune tools run ocamlformat by hand versus getting dune fmt to pick up the correct one?

if we need this kind of functionality, then rather than tool.version we can take an argument dune tools run --with-version 1.1.1 tool or something. The principle here is that collapsing two pieces of data into one string is usually not a good idea :)

Sure that works too. The reason I suggested this one is for users familiar with opam but its not a requirement.

Sudha247 · 2026-05-21T13:56:27Z

+
+CR-soon Alizter: `dune tools path` behavior is underspecified:
+
+- Should `path` trigger download and build if not yet built? Or only return path


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 · 2026-05-22T10:08:50Z

+CR-soon Alizter: Specify the RPC protocol for tool operations. What messages are
+needed? How does the watch server respond to tool additions?
+
+CR-soon Alizter: Document concurrent access behavior. What happens if two


It's useful to address this soon - in particular what should be the behaviour of Dune when this happens.

Sudha247 · 2026-05-22T10:23:54Z

+
+#### PATH fallback
+
+When a tool is not installed via the tool manager, fall back to system PATH.


This is presumably also to accommodate platform tools trying to use dune tools. In which case it would be useful to solicit opinions of platform tools developers on this.

Sudha247 · 2026-05-22T10:41:21Z

+
+#### 6.2. Automatic updates
+
+Tools do not auto-update; explicit user action is required.


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 · 2026-05-22T10:49:56Z

+
+The following are explicitly out of scope:
+
+#### 6.1. System-wide installation


The OCaml Platform does state that Dune is intended to be the front-end of the OCaml ecosystem. If we decide to move away from this, it has to be clearly documented so as not to confuse users.

Sudha247 · 2026-05-22T10:51:04Z

+#### 6.3. Tools for tools
+
+Using tools while developing the tools themselves (or their dependencies) has
+nuances related to the "in and out" problem ([#8652]).


In addition to what Shon has said above, now that in-and-out is being actively worked on, this needs to be revisited.

Sudha247 · 2026-05-22T10:53:48Z

+;; Using a binary package repository
+(tool
+ (package ocaml-lsp-server)
+ (repositories binary-packages))


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

Sudha247 · 2026-05-22T10:56:35Z

+
+## Learnings from the Prototype
+
+CR-soon Alizter: This entire section may be considered garbage. Extract


This needs a pass before merging.

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>

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

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.

But make this a "SHOULD" rather than a "MUST" Signed-off-by: Shon Feder <shon.feder@gmail.com>

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>

shonfeder marked this pull request as draft January 26, 2026 03:33

shonfeder mentioned this pull request Jan 26, 2026

Redesign and reimplement support for dev tools #12914

Open

3 tasks

shonfeder requested a review from Alizter January 26, 2026 03:39

shonfeder force-pushed the tools-design branch from 7f68d71 to 884541d Compare January 26, 2026 22:05

Sudha247 reviewed Mar 6, 2026

View reviewed changes

shonfeder commented Mar 10, 2026

View reviewed changes

Alizter reviewed Mar 10, 2026

View reviewed changes

Leonidas-from-XIV reviewed Apr 1, 2026

View reviewed changes

shonfeder commented Apr 14, 2026

View reviewed changes

Sudha247 mentioned this pull request Apr 16, 2026

Add reference docs for dune tools #14198

Merged

Sudha247 reviewed May 21, 2026

View reviewed changes

Sudha247 requested changes May 22, 2026

View reviewed changes

shonfeder force-pushed the tools-design branch from 2fe12d7 to fca86c1 Compare May 26, 2026 05:49

shonfeder and others added 9 commits May 29, 2026 23:06

Add initial draft of tool management design

609a102

Signed-off-by: Shon Feder <shon.feder@gmail.com>

update opening paragraph

b03b1a5

Signed-off-by: Ali Caglayan <alizter@gmail.com>

remove terminology section

0f63fd8

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>

fix numbering

68bb3f9

Signed-off-by: Ali Caglayan <alizter@gmail.com>

update requirements, issues and research

e7bb128

Signed-off-by: Ali Caglayan <alizter@gmail.com>

Make design principles its own section

b32704c

Signed-off-by: Shon Feder <shon.feder@gmail.com>

shonfeder added 16 commits May 29, 2026 23:06

Consolidate and fix terminology

fbc5106

- Drop implementation details from definition of "install" - Redefine "available" in terms of "install" as "installable" Signed-off-by: Shon Feder <shon.feder@gmail.com>

Fix section order

07c68ac

- Everything but summary after TOC - "how to read doc" sections should be first Signed-off-by: Shon Feder <shon.feder@gmail.com>

Fixes to how to read

56eceea

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

Explain design principles

13020ec

Signed-off-by: Shon Feder <shon.feder@gmail.com>

Define a well formed opam package

31e8b60

Signed-off-by: Shon Feder <shon.feder@gmail.com>

Fix roadmap reference

ce2ad6c

Make it clear that, while compatability is required, satisfaction is not. Signed-off-by: Shon Feder <shon.feder@gmail.com>

Fix generality

b0437e8

Reference to legacy system is not relevant for requirements (could be in implementation) Signed-off-by: Shon Feder <shon.feder@gmail.com>

rm outdated CR

5f1c18a

Signed-off-by: Shon Feder <shon.feder@gmail.com>

Move CR into "Ideas" section

4f5f0a3

These are design ideas for possible functionality, they are not relevant to functional specifications.

Recover system wide req

1e761d5

But make this a "SHOULD" rather than a "MUST" Signed-off-by: Shon Feder <shon.feder@gmail.com>

Move idea

9442bba

Signed-off-by: Shon Feder <shon.feder@gmail.com>

Open problem on version consistency

d986c32

Signed-off-by: Shon Feder <shon.feder@gmail.com>

Recover shells requirement

b93b7a9

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>

Fix programatic use

02565a1

Not sure why this overspecification and reduction in generality. We want the general usability. Signed-off-by: Shon Feder <shon.feder@gmail.com>

shonfeder force-pushed the tools-design branch from a1fb234 to 02565a1 Compare May 30, 2026 03:08


		CR-soon Alizter: Edge cases to specify:

		- Tool not locked: error with suggestion to run `dune tools add`?


		#### 5.1. Format rules (`dune fmt`, `dune build @fmt`)

		`dune fmt` must use tools managed by `dune tools`. This includes respecting


		The following are explicitly out of scope:

		#### 6.1. System-wide installation

		- Clean source tree: All tool artifacts live in `_build/`, not your repo
		- Multi-version: Different projects can use different tool versions


		See [Directory structure](#directory-structure) for storage locations.

		CR-soon Alizter: Once we have the relocatable compiler, tools being built will


		CR-soon Alizter: `dune tools path` behavior is underspecified:

		- Should `path` trigger download and build if not yet built? Or only return path


		#### PATH fallback

		When a tool is not installed via the tool manager, fall back to system PATH.


		#### 6.2. Automatic updates

		Tools do not auto-update; explicit user action is required.


		## Learnings from the Prototype

		CR-soon Alizter: This entire section may be considered garbage. Extract

Conversation

shonfeder commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Alizter commented Mar 6, 2026

Uh oh!

Sudha247 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shonfeder Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Leonidas-from-XIV left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

shonfeder commented Jan 26, 2026 •

edited

Loading

shonfeder Apr 14, 2026 •

edited

Loading