fix(cli): derive uipath pin in new scaffold from installed version

[andreibalas-uipath]

uipath new scaffolded a pyproject.toml with a hard-coded uipath>=2.10.0, <2.11.0 dependency that hadn't been bumped since 2.10, so the very next documented step (uv sync) downgraded the project's venv to 2.10.x on machines running 2.14.x (UiPath Jira UV-16117, Issue 1).

The fix: generate_pyproject() now derives the pin from the installed distribution (via the existing _get_safe_version()), keeping the same >=X.Y.0, <X.(Y+1).0 shape — pre-release/local suffixes are stripped — so uv resolution behavior is unchanged and only the numbers move. For every normal install (pip/uv/uv tool install) this is the path that runs.

The fallback: only when package metadata is unavailable (_get_safe_version() returns "unknown", e.g. a source checkout run without installing) does it fall back to a literal range generated from a single constant, FALLBACK_UIPATH_MINOR = "2.14", and print a warning. test_fallback_pin_admits_installed_uipath runs against the real installed package in CI and asserts the fallback admits the current release, so a future release PR that forgets to bump the constant fails CI instead of silently rotting. A second regression guard asserts the pin actually written by uipath new contains the installed uipath version.

Also in the scaffold path: the Initialize project hint's stray leading space is gone (it stays uipath init — with the pin derived from the running install, no sync step is needed before init). uipath.json now includes a GUID id (using the same resolve_existing_project_id(...) or uuid4() expression init uses for backfill), so new no longer emits 'id' field not present in uipath.json right after creating the file. packaging is declared as a dev dependency (the tests import it; previously only transitive via pytest), and docs/core/agents.md no longer shows uipath-langchain>=2.0 — that package is 0.x, so the spec resolved to nothing.

Package version bumped 2.14.8 → 2.14.9 per repo convention (every PR touching packages/uipath bumps the patch version; 2.14.8 was released by #1870 while this PR was open).

Follow-up (separate repos): the plugin CLIs (uipath-langchain, uipath-llamaindex, uipath-openai-agents) have the same stale-pin pattern; each should derive from its own installed version with its own minor as fallback and the same guard test.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates uipath new to derive scaffolded dependency pins from the installed UiPath version.

Changes:

• Adds version-aware dependency generation with fallback handling.
• Adds tests for version derivation, prereleases, fallback behavior, and scaffold output.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Summary
packages/uipath/tests/cli/test_new.py	Tests dynamic dependency pin generation and scaffolding behavior.
packages/uipath/src/uipath/_cli/cli_new.py	Generates version-aware dependency pins. Critical: combine the importlib.metadata imports to resolve Ruff I001.

Suppressed comments (1)

packages/uipath/src/uipath/_cli/cli_new.py:53

• This parser only accepts a bare numeric major.minor prefix, so a valid PEP 440 distribution version with an epoch (for example 1!2.14.0) or a v prefix reaches this branch and emits the stale 2.10 range even though metadata was found. That can reintroduce the downgrade this change is meant to prevent; parse a normalized PEP 440 version (or fail rather than using the old fallback) for present distributions.

    match = re.match(r"^(\d+)\.(\d+)", installed)
    if match is None:
        console.warning(
            f"Could not parse installed 'uipath' version '{installed}'; "
            f"falling back to '{_FALLBACK_UIPATH_DEPENDENCY_SPEC}'."

---

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

[github-actions]

🚨 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 →

[andreibalas-uipath]

Manual end-to-end verification (local build 2.14.9, commit 85ea80c; hint since reverted to uipath init in 141d107)

Ran the UV-16117 repro against a wheel built from this branch, in a fresh venv, macOS / Python 3.13.

1. Build & install

$ uv build                       # → dist/uipath-2.14.9-py3-none-any.whl
$ uv venv && uv pip install dist/uipath-2.14.9-py3-none-any.whl
$ .venv/bin/uipath --version
uipath version 2.14.9

2. uipath new

$ uipath new demo
✓  Created 'main.py' file.
✓  Created 'pyproject.toml' file.
✓  Created 'uipath.json' file.
💡 Initialize project: uipath init          # (was `uv sync && uipath init` at 85ea80c4; reverted in 141d107d)
💡 Run project: uipath run main '{"message": "Hello World!"}'

$ grep uipath pyproject.toml
    "uipath>=2.14.0, <2.15.0"

$ cat uipath.json
{ "id": "3fa013dd-1d9e-4081-b88e-61c7f6a9ed03", "functions": { "main": "main.py:main" } }

3. uv sync

$ uv sync
 - uipath==2.14.9 (from file:///…/dist/uipath-2.14.9-py3-none-any.whl)
 + uipath==2.14.8

Stays on the 2.14 line — before this fix the same step printed + uipath==2.10.73. The one-patch step to the released 2.14.8 happens only because 2.14.9 is not on PyPI yet; uv resolves from pyproject.toml and cannot see the locally installed wheel.

4. uipath init / uipath run on the local 2.14.9 build

To keep the local wheel through uv sync, a second copy of the scaffold got [tool.uv.sources] uipath = { path = "…/uipath-2.14.9-py3-none-any.whl" } appended; uv sync then reported Checked 61 packages with no change.

$ uipath --version
uipath version 2.14.9

$ uipath init
✓  Created '.env' file.
✓  Created 'bindings.json' file.
✓  Created 'entry-points.json' file with 1 entrypoint(s).
✓  Created 1 mermaid diagram file(s).
✓  Created 'project.uiproj' file.
✓  Created '.uipath/studio_metadata.json' file.
✓  Created AGENTS.md files and Claude Code skills.

$ uipath run main '{"message": "Hello World!"}'
output
└── message: Hello World!
✓  Successful execution.

$ uv pip show uipath | grep Version
Version: 2.14.9

No 'id' field not present in uipath.json warning and no id backfill step — new wrote it. (init/run were also executed on the venv that uv sync had moved to the released 2.14.8; output was identical.)

Baseline for comparison — released 2.14.8 (unfixed), same machine

$ uipath --version
uipath version 2.14.8
$ uipath new baseline
💡  Initialize project: uipath init
'id' field not present in uipath.json
$ grep uipath pyproject.toml
    "uipath>=2.10.0, <2.11.0"

Acceptance criteria from UV-16117 all hold: pin derived from the running CLI, uv sync does not downgrade, uipath.json carries an id, hint has no stray space.

Note: the 4 failing model-onboarding checks are an upstream regression in uipath-langchain-python (4b98dbaf, fixed by UiPath/uipath-langchain-python#1050), unrelated to this change — the same jobs passed on every earlier SHA of this branch.

[radu-mocanu]

why was this needed?

[andreibalas-uipath]

Just a documentation inconsistency that was referencing an invalid uipath-langchain version.

[sonarqubecloud]

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