Skip to content

Move dev-tool lock dirs into hidden folder #12671

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 14 commits into
base: main
Choose a base branch
from
Open

Move dev-tool lock dirs into hidden folder #12671

wants to merge 14 commits into from
+255 −118

Conversation

@Leonidas-from-XIV
Copy link
Collaborator

@Leonidas-from-XIV Leonidas-from-XIV commented Nov 4, 2025 •
edited by Alizter
Loading

This follows the discussion from the 29th of October where we decided that the dev-tools can (for now) live in a directory that is unlikely to be committed to git.

closes #12097

@Alizter
Copy link
Collaborator

Alizter commented Nov 4, 2025

You can interpret the statement "move dev-tool lock dirs into hidden folder" in two different ways. Either that the dev-tool.lock folder becomes hidden or the folder actually gets moved to a hidden location.

When we discussed this I initially meant the latter case. Doing something like slotting it in _build/ seems sensible.

All the issues we have with people complaining about the folder currently will not go away when we make the directory hidden IMO.

@shonfeder
Copy link
Member

shonfeder commented Nov 4, 2025

slotting it in _build/ seems sensible

This makes sens to me too!

@davesnx
Copy link
Contributor

davesnx commented Nov 5, 2025

I'm out of the conversation, but I wonder if dev-tools folder could be inside dune.lock folder?

@Alizter
Copy link
Collaborator

Alizter commented Nov 5, 2025

The issue we have here is that we don't want people committing their developer tool lock files but we don't mind people committing the build locks. If we merge them, then we cause problems for both parties.

@davesnx
Copy link
Contributor

davesnx commented Nov 5, 2025

Right, I figure it out but maybe up to them? If it's the only issue, can place a .gitignore inside dune-lock?

Place it under _build means that any rm -rf would cause issues

@Leonidas-from-XIV
Copy link
Collaborator Author

Leonidas-from-XIV commented Nov 5, 2025

Place it under _build means that any rm -rf would cause issues.

It would not, as then Dune will recreate the build plan for dev-tools if it does not exist. This is what it is doing at the moment already if you delete your dev-tools.locks/<lock-dir>.

@Leonidas-from-XIV Leonidas-from-XIV force-pushed the dev-tool-dotfiles branch 4 times, most recently from 7a2d49f to 4c44f66 Compare November 7, 2025 14:09
@Leonidas-from-XIV Leonidas-from-XIV marked this pull request as ready for review November 7, 2025 14:09
Alizter
Alizter reviewed Nov 7, 2025
View reviewed changes
@shonfeder shonfeder mentioned this pull request Nov 7, 2025
Closed
@Leonidas-from-XIV Leonidas-from-XIV force-pushed the dev-tool-dotfiles branch 2 times, most recently from 57e78aa to 8cc6508 Compare November 10, 2025 13:47
@shonfeder
Copy link
Member

shonfeder commented Nov 10, 2025

I believe this is read for another round of reviews :)

rgrinberg
rgrinberg reviewed Nov 10, 2025
View reviewed changes
src/dune_rules/utop.ml Outdated
Fs_memo.dir_exists (In_source_dir path))
lazy
(let path = Lock_dir.dev_tool_untracked_lock_dir Utop in
Path.Untracked.exists path)
Copy link
Member

@rgrinberg rgrinberg Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would this work in watch mode without Fs_memo?

Copy link
Collaborator

@Alizter Alizter Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It won't, but that wasn't the goal here. Fs_memo requires Path.Outside_build_dir which is going to have to be expanded if we are to account for _build/something-that's-not-a-context.

rgrinberg
rgrinberg reviewed Nov 10, 2025
View reviewed changes
@Leonidas-from-XIV Leonidas-from-XIV force-pushed the dev-tool-dotfiles branch 2 times, most recently from 7a26281 to 9e80516 Compare November 12, 2025 16:33
@Alizter Alizter self-requested a review November 19, 2025 19:51
@Alizter
Copy link
Collaborator

Alizter commented Nov 19, 2025

I've pushed a patch which uses fs_memo to scan the lock directories.

@Leonidas-from-XIV Leonidas-from-XIV force-pushed the dev-tool-dotfiles branch 2 times, most recently from 7f8be0c to bf0edc1 Compare November 20, 2025 10:33
@Sudha247 Sudha247 mentioned this pull request Nov 20, 2025
Open
Leonidas-from-XIV and others added 14 commits November 21, 2025 10:36
@Leonidas-from-XIV
Move dev-tool lock dirs from source into into build folder
fd86b9f 
Signed-off-by: Marek Kubica <[email protected]>
@Leonidas-from-XIV
Use Path type
d0765fe 
Signed-off-by: Marek Kubica <[email protected]>
@Leonidas-from-XIV
Turn the dev-tool path to a Path.External.t
29536dd 
Signed-off-by: Marek Kubica <[email protected]>
@Leonidas-from-XIV
Fix after rebase
8be9169 
Signed-off-by: Marek Kubica <[email protected]>
@Leonidas-from-XIV
Remove unused indirection
103e334 
Signed-off-by: Marek Kubica <[email protected]>
@Leonidas-from-XIV
Rewrite absolute external paths into relative paths
90303b7 
Signed-off-by: Marek Kubica <[email protected]>
@Leonidas-from-XIV
Bring back Fs_memo
d540a08 
Signed-off-by: Marek Kubica <[email protected]>
@Leonidas-from-XIV
Improve implementation of external to source mapping
bca2167 
Signed-off-by: Marek Kubica <[email protected]>
@Leonidas-from-XIV
Closer to style of main
40ff99f 
Signed-off-by: Marek Kubica <[email protected]>
@Leonidas-from-XIV
Add validation that path to be deleted is in fact managed
e3f24bf 
Signed-off-by: Marek Kubica <[email protected]>
@Leonidas-from-XIV
Use try_localize instead of rolling my own version of it
d5a4172 
Signed-off-by: Marek Kubica <[email protected]>
@Leonidas-from-XIV
Do not assume build dir name
b629734 
Signed-off-by: Marek Kubica <[email protected]>
@Leonidas-from-XIV
Add cram test to show that custom build dirs work
91fa869 
Signed-off-by: Marek Kubica <[email protected]>
@Alizter @Leonidas-from-XIV
use fs_memo to scan lock directories
d767790 
Signed-off-by: Ali Caglayan <[email protected]>
@Leonidas-from-XIV
Copy link
Collaborator Author

Leonidas-from-XIV commented Nov 21, 2025 •
edited
Loading

Somehow the "re-request review" button doesn't do anything, but anyway, I think this PR is ready for re-review. cc @Alizter @rgrinberg

@Alizter Alizter requested review from Alizter and rgrinberg and removed request for Alizter, ElectreAAS, Sudha247, punchagan and rgrinberg November 21, 2025 10:41
rgrinberg
rgrinberg requested changes Nov 21, 2025
View reviewed changes
src/dune_rules/format_rules.ml
Source_tree.find_dir path >>| Option.is_some
Lock_dir.dev_tool_external_lock_dir Ocamlformat
|> Path.external_
|> Path.Untracked.exists
Copy link
Member

@rgrinberg rgrinberg Nov 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason why we're still breaking watch mode here? It's not really required to keep it working, but don't see why it's needed to intentionally break it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@rgrinberg rgrinberg rgrinberg requested changes

@Alizter Alizter Awaiting requested review from Alizter

Requested changes must be addressed to merge this pull request.

Assignees

@Leonidas-from-XIV Leonidas-from-XIV

Labels

package management

Projects

None yet

Milestone

[pkg]: Minimal Stable Product

Development

Successfully merging this pull request may close these issues.

dune-pkg: do not write lock directories into the worktree by default

5 participants

@Leonidas-from-XIV @Alizter @shonfeder @davesnx @rgrinberg