Treat workspace members with an intermediate pyproject.toml as standalone

[konstin]

Handle the case where a pyproject.toml sits between a member and its workspace root.

This unintentionally supported case regressed when adding workspace caching, which
memorizes which projects are workspace members without traversing upwards, ignoring the
pyproject.toml in the middle. Before caching, workspace discovery for this project
starting from the project itself would terminate at the intermediate pyroject.toml and
treat it as standalone project, which this hack restores.

Fixes #19916

[astral-sh-bot]

uv test inventory changes

This PR changes the tests when compared with the latest main baseline.

• Added tests: 2
• Removed tests: 0
• Changed suites: 1

uv::lock: +2 / -0

Added:

• uv::lock::lock::lock_no_workspace_source_nested_project
• uv::lock::lock::lock_workspace_member_with_standalone_path_source

Removed: none

[EliteTK]

I think fundamentally this doesn't actually change which workspace a package sees. Which lets things leak in from the outer workspace like so:

#!/usr/bin/env bash

cargo build --profile fast-build --bin uv || exit 125
uv=$PWD/target/fast-build/uv
tmpdir=$(mktemp -d) || exit 125
trap 'rm -rf "$tmpdir"' exit

cd "$tmpdir" || exit 125

mkdir -p packages/{app,lib} || exit 125

cat <<EOF >pyproject.toml || exit 125
[tool.uv.workspace]
members = [
    "packages/app",
    "packages/lib",
]
EOF

cat <<EOF >packages/pyproject.toml || exit 125
[project]
name = "packages"
version = "0.1.0"
EOF

cat <<EOF >packages/app/pyproject.toml || exit 125
[project]
name = "app"
version = "0.1.0"
requires-python = ">=3.11"
dependencies = ["lib"]

[tool.uv.sources]
lib = { workspace = true }
EOF

cat <<EOF >packages/lib/pyproject.toml || exit 125
[project]
name = "lib"
version = "0.1.0"
EOF

output=$tmpdir/output

# Should fail to lock with an error
"$uv" lock --offline && exit 1
exit 0

I think this is maybe acceptable as it shouldn't break things? I'm not sure.

But I think a cleaner, possibly similarly simple fix would be to avoid inserting the member-root → outer-workspace cache entry when there is an intermediate pyproject.toml between that member and the workspace root.

[EliteTK]

This I believe is actually broader than it used to be. We'd parse the intermediate files to check for certain qualities, not merely check they exist.

[EliteTK]

Given the limitations of this approach, I am not sure if we should use this name.

[EliteTK]

Suggested change

	// starting from the project itself would terminate at the intermediate `pyroject.toml` and
	// starting from the project itself would terminate at the intermediate `pyproject.toml` and