fix(cli): add --type to uipath new so function projects stay reachable by vldcmp-uipath · Pull Request #1886 · UiPath/uipath-python

vldcmp-uipath · 2026-09-07T14:54:03Z

Problem

When an agent framework integration such as uipath-langchain is installed, its entry-point middleware claims uipath new unconditionally (should_continue=False in all cases), so the base function scaffold is unreachable — uipath new <name> always produces an agent project with no uipath.json. Fixes #1543.

Changes

The fix lives in the dispatch, not in the integrations. The new middleware chain is the only route to an agent scaffold, and cli_new.py is its only caller, so the base CLI decides whether the frameworks are consulted at all:

--type auto (the new default) preserves today's behaviour — an installed framework claims the scaffold; with none installed, the base function project is created.
--type function never calls the chain, so no installed framework can intercept it. This is the option callers needing a guaranteed function project (e.g. the uip functions-tool passthrough) should pass.
--type agent calls the chain and errors when nothing claims it, instead of quietly producing a function project. It is a guarantee, which is what makes it useful in CI.
--agent-framework picks between installed frameworks: uipath new my-agent --type agent --agent-framework uipath-langchain. It takes the integration package, spelled exactly as the error messages list it, is only valid with --type agent, and dispatches to that framework alone so another cannot claim the scaffold first. With one framework installed there is nothing to choose and it is optional; with several and no choice given, the command warns — naming the installed frameworks and the one it picked — and scaffolds with the first discovered, preserving the pre---type behaviour rather than breaking those environments.

There is still no list of frameworks in the base package — no enum, no framework-to-package map, nothing to update when an eighth integration ships. The frameworks that exist, and the names --agent-framework accepts, are derived from the registered new middlewares and the distributions that registered them, so a framework this CLI has never heard of is named and selected like any other.

Integrations need no changes. Middlewares.next("new", name) is byte-identical to today's call, so existing releases keep working as they are, with no new uipath floor, no kwargs, and no legacy-signature warnings.

Behaviour

Installed integrations	`uipath new x` (auto)	`uipath new x --type function`	`uipath new x --type agent`
none	function project	function project	error: install an agent framework
one	that framework's agent	function project	that framework's agent
several	warns, scaffolds with the first discovered	function project	warns, scaffolds with the first discovered

Testing

21/21 in tests/cli/test_new.py, 1490/1490 across tests/cli; mypy and ruff clean.
Verified end-to-end in a venv against unmodified uipath-langchain 0.17.8 from its main: auto scaffolds the LangGraph agent, --type function now reaches the base scaffold (the bug), --type agent scaffolds the agent. With a second integration installed, both auto and agent warn and scaffold with the first discovered framework while --type function still succeeds; --agent-framework uipath-langchain selects explicitly, and a value that is not an installed package lists the ones that are.
Docs build clean; the rendered CLI reference shows the three --type choices.

🤖 Generated with Claude Code

Development Packages

uipath

[project]
dependencies = [
  # Exact version (copy-paste ready):
  "uipath==2.14.23.dev1018867682",

  # Any version from this PR (uncomment to use a range instead):
  # "uipath>=2.14.23.dev1018860000,<2.14.23.dev1018870000",
]

[[tool.uv.index]]
name = "testpypi"
url = "https://test.pypi.org/simple/"
publish-url = "https://test.pypi.org/legacy/"
explicit = true

[tool.uv.sources]
uipath = { index = "testpypi" }

Copilot

🟢 Approval recommended

The behavior change is well-covered by tests and the remaining feedback is limited to minor CLI help/UX clarity rather than functional correctness.

Pull request overview

This PR updates the uipath CLI’s new command to make function vs agent scaffolding explicit, preventing third-party integrations (e.g., uipath-langchain) from unconditionally claiming uipath new and making the base function scaffold unreachable.

Changes:

Added --type function|agent (default function) and --agent-framework ... (valid only with --type agent) to uipath new, forwarding both as enums through the middleware chain.
Introduced shared StrEnum models (ProjectType, AgentFramework) for integrations to import, including framework→package name mapping.
Expanded CLI test coverage for the new option matrix and bumped version to 2.14.13.

File summaries

File	Description
packages/uipath/src/uipath/_cli/cli_new.py	Adds `--type` / `--agent-framework`, resolves defaults, validates combinations, forwards enums to middleware, and errors when an agent scaffold isn’t claimed.
packages/uipath/src/uipath/_cli/models/project_types.py	New `ProjectType` StrEnum for integrations and middleware dispatch.
packages/uipath/src/uipath/_cli/models/agent_frameworks.py	New `AgentFramework` StrEnum with `.package` mapping and default framework constant.
packages/uipath/tests/cli/test_new.py	Adds tests verifying defaulting, forwarding, validation, and “missing integration” error behavior.
packages/uipath/pyproject.toml	Bumps `uipath` version to `2.14.13`.
packages/uipath/uv.lock	Updates lock metadata and bumps locked `uipath` version to `2.14.13`.

Review details

Files reviewed: 5/6 changed files
Comments generated: 1
Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

+    type=click.Choice([f.value for f in AgentFramework]),
+    default=None,
+    show_default=DEFAULT_AGENT_FRAMEWORK.value,
+    help="Agent framework to scaffold for. Only valid together with `--type agent`.",


Temporary, to validate and publish a dev build of this PR before uipath 2.14.13 ships: pin uipath==2.14.13.dev1018867574 (built from UiPath/uipath-python#1886) and source it from the testpypi index. Restore the ">=2.14.13, <2.15.0" range and drop the source before merging. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Temporary, to validate and publish a dev build of this PR before uipath 2.14.14 ships: pin uipath==2.14.14.dev1018867580 (built from UiPath/uipath-python#1886) and source it from the testpypi index. Restore the ">=2.14.14, <2.15.0" range and drop the source before merging. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

`uipath new` ships no `--agent-framework` option: the core takes the framework from whichever integration package is installed, and fails when several are (UiPath/uipath-python#1886). Framework Selection still told readers the flag existed, which would have them type an option the command rejects. State the two type values that do exist, note that the framework cannot be named on the command line, and record the several-installed failure so "install exactly one" reads as a requirement rather than a preference. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VqfFdgnQFGJ8EPGXn6HC82

`uipath new` was unconditionally hijacked by any installed agent framework integration (their middleware always returned should_continue=False), making the base function scaffold unreachable once uipath-langchain was in the environment (#1543). The fix is in the dispatch rather than in the integrations: the `new` middleware chain is the only way an agent scaffold happens, and the base CLI now decides whether to consult it at all. - `--type auto` (the new default) keeps today's behaviour: an installed framework claims the scaffold, otherwise a function project is created. - `--type function` never consults the chain, so no installed framework can intercept it. - `--type agent` consults the chain and fails when nothing claims it, rather than quietly producing a function project. The framework is never named on the command line: it is whichever integration package the environment has. With several installed the command errors instead of resolving by registration order, naming the packages it found — discovered from the registered middlewares and their entry points, so the CLI never hardcodes the list of frameworks that exist. Integrations need no changes and no new uipath floor; `Middlewares.next("new", name)` is unchanged. Docs cover the new option: the previously missing `new` section in the CLI reference, a Claude Agent SDK row in the coded-agents framework table, and explicit-type notes in the agents, functions and Studio Web guides. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

- Move AGENT_FRAMEWORKS_DOCS_URL to _cli/_utils/_constants.py. - Drop the ProjectType module docstring's note about which packages import it: the integrations no longer do. - Trim the explanation from _installed_agent_framework_packages() and from the middleware-chain comment in the command. - State what `--type function` guarantees in its test, instead of pointing at the issue it came from. - Drop "Using the installed '<framework>' agent framework." from the CLI reference transcript: the command no longer resolves a framework by name, so it no longer prints that line. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

With several agent framework packages in the same environment, `uipath new` could only report the ambiguity and ask for one to be uninstalled. It now takes the choice on the command line: uipath new my-agent --type agent --agent-framework uipath-langchain The value is the integration package, spelled exactly as the errors list it, and the scaffold is dispatched to that framework alone rather than through the chain, so another one cannot claim it first. Naming a framework that is not installed lists the ones that are, and the option stays limited to `--type agent`. The accepted values are still discovered, never hardcoded: frameworks come from the registered `new` middlewares, named after the distribution that registered them, so a framework this CLI has never heard of can be selected by name like any other. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

github-actions · 2026-09-18T12:01:04Z

🚨 Heads up: `uipath-langchain` cross-tests are FAILING 🚨

Your changes may break the uipath-langchain-python integration.

⚠️ These checks are NOT enforced by branch protection rules. Please review the failures before merging.

🔍 Inspect the failed run →

radu-mocanu · 2026-09-18T12:55:31Z

+        console.error(
+            "Multiple agent frameworks are installed: "
+            + ", ".join(framework.package for framework in installed)
+            + f".\nPick one with `uipath new {name} --type agent "
+            "--agent-framework <framework>`, or run "
+            f"`uipath new {name} --type function` to create a function project."
+        )


this is a breaking change. let s warn that there are multiple frameworks installed but the scaffold should not fail

Environments with more than one agent framework package scaffolded fine before `--type` existed — the first discovered integration claimed the project. Turning that into an error would be a breaking change, so the old outcome stays: `uipath new` warns, names all the installed frameworks and the one it picked, and scaffolds with the first discovered. `--agent-framework` remains the way to choose deliberately. The pick is dispatched to that framework's middleware directly, so the warning always names the integration that actually scaffolds. Discovery order is the entry-point order (a filesystem accident, stable per environment); listings shown to the user stay sorted. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

sonarqubecloud · 2026-09-18T13:40:12Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

Copilot AI lite review requested due to automatic review settings September 7, 2026 14:54

Copilot started reviewing on behalf of vldcmp-uipath September 7, 2026 14:54 View session

github-actions Bot added test:uipath-langchain Triggers tests in the uipath-langchain-python repository test:uipath-runtime test:uipath-integrations labels Sep 7, 2026

Copilot AI reviewed Sep 7, 2026

View reviewed changes

Comment thread packages/uipath/src/uipath/_cli/cli_new.py Outdated

Comment on lines +75 to +78

type=click.Choice([f.value for f in AgentFramework]),

default=None,

show_default=DEFAULT_AGENT_FRAMEWORK.value,

help="Agent framework to scaffold for. Only valid together with `--type agent`.",

vldcmp-uipath mentioned this pull request Sep 7, 2026

fix(cli): only claim uipath new scaffolds for langchain agents UiPath/uipath-langchain-python#1069

Closed

vldcmp-uipath added the build:dev Create a dev build from the pr label Sep 8, 2026

vldcmp-uipath force-pushed the fix/new-project-type-and-agent-framework branch from f6e07d4 to e38a166 Compare September 9, 2026 11:22

vldcmp-uipath mentioned this pull request Sep 9, 2026

docs(uipath-agents): one command per project type, no scaffold-type flag UiPath/skills#3165

Merged

vldcmp-uipath force-pushed the fix/new-project-type-and-agent-framework branch 2 times, most recently from 28a14dc to fe4e537 Compare September 11, 2026 12:24

vldcmp-uipath mentioned this pull request Sep 11, 2026

fix(cli): write pyproject.toml once when scaffolding a new agent UiPath/uipath-integrations-python#373

Closed

vldcmp-uipath changed the title ~~fix(cli): add --type and --agent-framework options to uipath new~~ fix(cli): add --type to uipath new so function projects stay reachable Sep 15, 2026

vldcmp-uipath force-pushed the fix/new-project-type-and-agent-framework branch 5 times, most recently from 5d9f76d to e35dc3b Compare September 15, 2026 14:32

vldcmp-uipath force-pushed the fix/new-project-type-and-agent-framework branch 5 times, most recently from a934a57 to 35a4063 Compare September 18, 2026 11:51

vldcmp-uipath and others added 3 commits September 18, 2026 14:59

vldcmp-uipath force-pushed the fix/new-project-type-and-agent-framework branch from 35a4063 to 129c451 Compare September 18, 2026 12:00

radu-mocanu reviewed Sep 18, 2026

View reviewed changes

vldcmp-uipath force-pushed the fix/new-project-type-and-agent-framework branch from 79e6f37 to 195fac3 Compare September 18, 2026 13:33

radu-mocanu approved these changes Sep 21, 2026

View reviewed changes

vldcmp-uipath merged commit 3e18950 into main Sep 21, 2026
187 checks passed

vldcmp-uipath deleted the fix/new-project-type-and-agent-framework branch September 21, 2026 07:50

Navigation Menu

fix(cli): add --type to uipath new so function projects stay reachable - #1886

fix(cli): add --type to uipath new so function projects stay reachable#1886
vldcmp-uipath merged 4 commits into
mainfrom
fix/new-project-type-and-agent-framework

vldcmp-uipath commented Sep 7, 2026 •

edited by github-actions Bot

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

github-actions Bot commented Sep 18, 2026

Uh oh!

radu-mocanu Sep 18, 2026

Uh oh!

sonarqubecloud Bot commented Sep 18, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

vldcmp-uipath commented Sep 7, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Changes

Behaviour

Testing

Development Packages

uipath

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟢 Approval recommended

Uh oh!

github-actions Bot commented Sep 18, 2026

🚨 Heads up: uipath-langchain cross-tests are FAILING 🚨

Uh oh!

radu-mocanu Sep 18, 2026

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud Bot commented Sep 18, 2026

Quality Gate passed

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

vldcmp-uipath commented Sep 7, 2026 •

edited by github-actions Bot

Loading

🚨 Heads up: `uipath-langchain` cross-tests are FAILING 🚨