Python: Clarify Foundry 1.12 Projects <2.4 bound and supported Projects 2.6 upgrade path #8103

Activity

1. github-project-automation

   added this to Agent Frameworkon Sep 6, 2026
2. agent-framework-automation

   added

   pythonUsage: [Issues, PRs], Target: PythonUsage: [Issues, PRs], Target: Python

   triageUsage: [Issues], Target: All issues that still need to be triagedUsage: [Issues], Target: All issues that still need to be triaged

   on Sep 6, 2026
3. arush-saxena commented on Sep 6, 2026

   

   arush-saxena

   on Sep 6, 2026

   Author

   More actions

   Additional bounded evidence: normal uv0.12.7 resolution rejects Foundry1.12.0 + Projects2.6.0 exactly because Projects>=2.2,<2.4 conflicts with==2.6.0. Separately, Python3.13.15 can resolve/install Core1.17.0 + olderFoundry1.10.1 + OpenAIadapter1.14.2 + Projects2.6.0 + OpenAI3.8.0 (HTTPX2 2.12.0), with uv pip check passing. Projects/Foundry client constructors and the safe Harness factory/local session construct offline; this does not exercise remote session creation, Responses, MCP or Azure authentication. We are not treating the older adapter range as support evidence or overriding1.12 bounds. The specific clarification remains: what known behavior or validation/support boundary keeps the current Foundry package capped below2.4, and what is the maintainer-recommended forward path? No production upgrade was made.
4. Evan Mattson (moonbox3)

   added the

   Bug

   issue type on Sep 7, 2026
5. github-actions

   assigned

   Eduard van Valkenburg (eavanvalkenburg)

   on Sep 7, 2026
6. github-actions

   removed

   triageUsage: [Issues], Target: All issues that still need to be triagedUsage: [Issues], Target: All issues that still need to be triaged

   on Sep 7, 2026
7. doruit commented on Sep 7, 2026

   

   Douwe van de Ruit (doruit)

   on Sep 7, 2026

   More actions

   Adding a real-world data point that confirms this is a live blocker, not just a theoretical question.

   We hit the exact same conflict via Dependabot on a public repo (doruit/forged-with-foundry): Dependabot repeatedly proposed bumping azure-ai-projects to >=2.4.0 while our agent-framework-foundry==1.11.0 pin still required <2.4.0, producing an unresolvable PR every time. We worked around it with an explicit Dependabot ignore rule for azure-ai-projects>=2.4.0 to stop the noise until this is resolved upstream.

   Separately, this thread surfaced something worth flagging for anyone reading it who's tempted to bump openai alone once agent-framework-openai gains an openai<4 upper bound (per #7967): doing so is incomplete, not just risky. agent-framework-foundry==1.11.0 (our currently pinned version) still transitively resolves to an agent-framework-openai release with openai<3. Bumping openai to a 3.x release without also bumping agent-framework-foundry to >=1.12.0 produces a package set that either fails to resolve, or (if pip backtracks to a different transitive patch version) installs "successfully" without ever having been exercised by agent-framework-foundry's own test matrix against that combination. A note in this issue (or in agent-framework-foundry's release notes) clarifying the minimum coherent {foundry, openai adapter, projects, openai} version set would help downstream Dependabot configs avoid exactly this trap.

   Happy to share our dependabot.yml workaround if useful as a reference.
8. Eduard van Valkenburg (eavanvalkenburg)

   closed this as completedin #8188on Sep 9, 2026
9. github-project-automation

   moved this to Done in Agent Frameworkon Sep 9, 2026