[IanButterworth]

#16229 created a bunch of superfluous PRs because I didn't realize julia compat wasn't being respected across linked Projects in the way Pkg does.

This fixes that.

What are you trying to accomplish?

The helper derived a project's stdlib compat floors from that file's own julia compat entry alone, and the parser wrote every Project.toml into its own isolated temp directory. A workspace member or a package's test/Project.toml usually has no julia entry, so it was treated as supporting every Julia release and got floors like Statistics = "0.0.0, 1" while the package beside it said julia = "1.10". That produced spurious widening PRs on those files.

This follows what Pkg enforces instead. The rule in effective_julia_compat (julia/helpers/DependabotHelper.jl/src/stdlibs.jl):

• A package (name and uuid, Pkg's env.pkg) uses only its own julia entry. It is also installed on its own, from a registry or by path, where nothing else applies, so a workspace it sits in must not narrow its compat entries. This covers the workspace root and any sub-package member.
• A workspace environment (test/, docs/, anything without name and uuid) intersects its own entry with every project in the workspace: root, siblings, nested members. That is exactly Pkg.Operations.get_compat_workspace, and Pkg.test runs a member test/ in place inside the workspace rather than in a sandbox, so there is no wider range to cover.
• A test/ environment outside a workspace intersects its own entry with the package in the parent directory, since the Pkg.test sandbox loads the package and Pkg.Operations.collect_project refuses a Julia its julia entry excludes. A test/ under a plain environment, or a test/ project that is itself a package, inherits nothing.

The Ruby parser now lays all project files out in one temp tree at their repository paths (via DependencyFile#path, which also resolves ../Project.toml safely) so Pkg can see those parents. A lone Project.toml behaves exactly as before.

Anything you want to highlight for special attention from reviewers?

An ancestor-only rule (member inherits from the workspace root) was the first cut; it was replaced by Pkg's own intersection over every workspace project because that is what the shared manifest actually resolves under, and a narrower sibling would otherwise be ignored. Packages are exempt on purpose: narrowing a package's compat entries to the workspace intersection would break installing it on its own.

At ecosystem scale only stdlib compat floors in workspace member files and test/Project.toml next to a package change, and only towards narrower ranges. The effect is fewer proposed widenings, never a new kind of PR. Outside a workspace test/Project.toml is not fetched today, so the sandbox rule only applies when a workspace lists test or Dependabot targets a test/ directory.

How will you know you've accomplished your goal?

New helper tests cover a workspace with root, siblings and a nested member (environments take the intersection, a sub-package keeps its own range), a package's test/ environment outside a workspace, a plain environment's test/ directory (no inheritance) and a test/ project that is itself a package. New parser specs cover the same cases end to end through the Ruby side, including a root fetched as ../Project.toml when Dependabot targets a member directory.

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.

[DilumAluthge]

In the cases listed, the new behavior looks correct to me.

SGTM.

[IanButterworth]

@robaiken should be ready for review