Cocoanetics / Cocoanetics/JSONFoundation

Swift 6.2.3 (Xcode 26.2 CLI) cannot fresh-resolve a dependent with traits: ["Subprocess"] — "exhausted attempts to resolve the dependencies graph"

Open
#8 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Swift
Stars
2
Forks
0
Avg merge
1h 30m
Merged PRs (30d)
3

Description

With the Xcode 26.2 default toolchain (Swift 6.2.3), a fresh swift package resolve (no Package.resolved) of any package depending on JSONFoundation with the Subprocess trait enabled fails deterministically:

error: exhausted attempts to resolve the dependencies graph, with the following dependencies unresolved:
* 'swift-subprocess' from https://github.com/swiftlang/swift-subprocess.git

Minimal repro (fails):

// swift-tools-version: 6.1
import PackageDescription
let package = Package(
    name: "probe",
    platforms: [.macOS("13.0")],
    dependencies: [
        .package(url: "https://github.com/Cocoanetics/JSONFoundation.git", from: "2.4.0", traits: ["Subprocess"])
    ],
    targets: [.target(name: "probe")]
)

Control experiments:

  • A package depending on swift-subprocess from: "0.5.0" directly: resolves fine — the package itself is resolvable.
  • The repro manifest plus a direct .package(url: swift-subprocess, from: "0.5.0") line: resolves fine — direct participation stabilizes the solver.

So the SwiftPM 6.2.3 solver fails specifically when swift-subprocess participates only via an enabled trait of a dependency — even though JSONFoundation declares the .package line unconditionally. Swift 6.3.1 (SwiftMCP CI) is unaffected; consumers with a valid lockfile are unaffected.

Impact: SwiftMCP itself (JSONFoundation with traits: ["Subprocess"]) cannot be fresh-resolved on the Xcode 26.2 toolchain — both swift package resolve and Xcode's own resolver fail. Bootstrap workaround: temporarily add the direct swift-subprocess dependency, resolve, remove it, keep the Package.resolved. Sibling of the resolver bug worked around in SwiftMCP d800f14. The real defect is SwiftPM's; this issue tracks it consumer-side (options: document the bootstrap, or declare swift-subprocess as a direct dependency until 6.2.x is irrelevant).

🤖 Generated with Claude Code

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the minimal Package.swift reproduction and run swift package resolve under Swift 6.2.3/Xcode 26.2, comparing it with the direct swift-subprocess dependency control. Check the resolver behavior for the enabled Subprocess trait and determine whether the issue should document the bootstrap workaround or track a direct dependency until the affected toolchain is no longer relevant.

Written by the indexing model from the issue text.

Assessment

Tech stack
swift
Domain
build-system, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.