[glenn-jocher]

Replaces actions/setup-python with ultralytics/actions/setup-uv. By default, that action now activates a venv on the newest Python preinstalled on the runner, with no Python download. Packages install into that venv, so --system is dropped. Jobs that pin a Python version keep the pin on setup-uv, which uses the preinstalled copy when the runner has one.

• Publish builds use uv build, which produced the same wheel contents, METADATA and sdist file list as python -m build in a local comparison. The SBOM scans the activated venv instead of a separate sbom-env and is named after the repository (SYFT_SOURCE_NAME) rather than the venv's runner temp path. The same SBOM job, run from the actions branch against a temporary draft release, produced a valid SPDX 2.3 document matching the last release's SBOM package for package.
• Drops hand-made venvs in favor of the activated one.

CI first ran against the setup-uv-defaults branch of ultralytics/actions#915. #915 is now merged (da5463a, released as 0.4.0), so setup-uv is back on @main, which carries the new defaults.

🛠️ PR Summary

_{Made with ❤️ by Ultralytics Actions}

🌟 Summary

The publish workflow now uses setup-uv’s activated Python environment for dependency installation, package builds, and SBOM generation.

📊 Key Changes

• Removed actions/setup-python; installs no longer use --system.
• Replaced python -m build with uv build.
• Removed the separate sbom-env; the SBOM scan uses the activated environment and names its source after the repository.

🎯 Purpose & Impact

• The publish workflow uses one managed environment instead of creating or targeting separate environments.
• The PR reports that the uv build output matches the previous build’s wheel contents, metadata, and sdist file list. The SBOM source name is now the repository rather than the runner’s temporary venv path.

[UltralyticsAssistant]

👋 Hello @glenn-jocher, thank you for submitting a ultralytics/mkdocs 🚀 PR! This automated message confirms your contribution was received, and an Ultralytics engineer will assist with the review. To ensure a seamless integration of your work, please review the following checklist:

• ✅ Define a Purpose: Clearly explain the purpose of your fix or feature in your PR description, and link to any relevant issues. Ensure your commit messages are clear, concise, and adhere to the project's conventions.
• ✅ Synchronize with Source: Confirm your PR is synchronized with the ultralytics/mkdocs main branch. If it's behind, update it by clicking the 'Update branch' button or by running git pull and git merge main locally.
• ✅ Ensure CI Checks Pass: Verify all Ultralytics Continuous Integration (CI) checks are passing. If any checks fail, please address the issues.
• ✅ Update Documentation: Update the relevant documentation for any new or modified features.
• ✅ Add Tests: If applicable, include or update tests to cover your changes, and confirm that all tests are passing.
• ✅ Sign the CLA: Please ensure you have signed our Contributor License Agreement if this is your first Ultralytics PR; the CLA check will comment with signing instructions if needed.
• ✅ Minimize Changes: Limit your changes to the minimum necessary for your bug fix or feature addition. "It is not daily increase but daily decrease, hack away the unessential. The closer to the source, the less wastage there is." — Bruce Lee

For more guidance, please refer to our Contributing Guide. Don't hesitate to leave a comment if you have any questions. Thank you for contributing to Ultralytics! 🚀

[UltralyticsAssistant]

🔍 PR Review

_{Made with ❤️ by Ultralytics Actions}

LGTM. Reviewed the publish, build, and SBOM workflow changes; no concrete regressions found. The temporary setup-uv-defaults branch is a short-lived integration dependency, as noted in the PR.

Superseded by new review

[UltralyticsAssistant]

🔍 PR Review 2

_{Made with ❤️ by Ultralytics Actions}

Since review 1, the diff shown is unchanged. I found a missed release-blocking mismatch: the workflow still references setup-uv@main, so it does not use the activation defaults this change depends on. This reverses the prior LGTM based on the action’s documented opt-in activation behavior.

💬 Posted 1 inline comment

• ⚠️ HIGH .github/workflows/publish.yml:33 This install now relies on an activated venv, but the workflow still uses setup-uv@main; the PR description says the new activation defaults are on setup-uv-defaults. On @main, activation is opt-in, so without --system this install has no target environment and fails. The SBOM step also relies on VIRTUAL_ENV being set. Pin the action to the defaults branch or explicitly enable activation before removing --system. (github.com)

[glenn-jocher]

ultralytics/actions#915 merged at 17:18 UTC (da5463a, released as 0.4.0), so setup-uv@main now carries the new defaults and this CI run exercises them. The validation commit pointing at @setup-uv-defaults was already reverted, and the PR description is updated to match.

[glenn-jocher]

ultralytics/actions#915 merged at 17:18 UTC (da5463a, released as 0.4.0), so setup-uv@main now carries the new defaults and this CI run exercises them. The validation commit pointing at @setup-uv-defaults was already reverted, and the PR description is updated to match.

[UltralyticsAssistant]

🔍 PR Review 3

_{Made with ❤️ by Ultralytics Actions}

Since review 2, the setup-uv defaults concern is resolved by the action update described in the PR discussion. This diff removes the separate Python and hand-made venv setup, uses the activated environment for installs and SBOM scanning, and switches the build to uv build. No remaining concrete regressions found; LGTM.

[UltralyticsAssistant]

🎉 This PR has been merged—thank you, @glenn-jocher!

“Alone we can do so little; together we can do so much.” — Helen Keller

Using setup-uv’s activated environment across dependency installation, builds, and SBOM generation brings the publish workflow’s steps together in one managed environment.