Skip to content

Conversation

@IanButterworth
Copy link
Contributor

@IanButterworth IanButterworth commented Nov 9, 2025

What are you trying to accomplish?

Currently I don't believe its possible to update manifest/lock files that reside in different directories.
In julia's workspaces that's a design feature. Multiple manifests can share the same lock file in a parent dir (not strictly the immediate parent either)

This is a draft of getting that working. I couldn't figure out how to make it work without changing core functions.

Paired with dependabot/cli#537

Developed with help from Claude and Codex 🤖 🤖

Summary

  • Add associated_manifest_paths / associated_lockfile_path metadata to DependencyFile so shared lockfiles survive directory filtering and expose ashared_across_directories? helper.
  • Teach the Julia file fetcher/parser/updater to populate and respect the new metadata: workspaces now send every sibling Project.toml plus the sharedManifest.toml to each updater run, and relative manifest paths returned by the helper are resolved back to their canonical repo locations.
  • Update the Julia helper/utilities to detect workspace members via Pkg, document the architecture in julia/DEVDOCS.md, refresh julia/README.md, and cover the new behaviour in Ruby specs (dependency change builder / dependency snapshot batching / Julia file updater).
  • Implemented deferred workspace warnings without touching core builder:
    • Added lightweight per-manifest tracking (stored on the Julia file updater) so we know which workspace directories have already been processed. update_workspace_sibling_projects now skips directories we’ve already updated, meaning other_updated_projects only reflects remaining runs.
    • When the helper fails, we only emit the julia_manifest_not_updated notice if there are no sibling updates pending; the first failure in a multi-directory workspace no longer spams warnings, while the last failure still surfaces the alert.
    • Introduced reset_processed_manifest_directories! for tests, plus new specs covering the “fails then succeeds” and “fails everywhere” scenarios.

TODO

Anything you want to highlight for special attention from reviewers?

How will you know you've accomplished your goal?

Checklist

  • I have run the complete test suite to ensure all tests and linters pass.
  • I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
  • I have written clear and descriptive commit messages.
  • I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
  • I have ensured that the code is well-documented and easy to understand.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant