-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add uv sync --script
#11361
Add uv sync --script
#11361
Conversation
9626138
to
f45a246
Compare
8e6f8ed
to
b8f6f85
Compare
f45a246
to
794d063
Compare
b8f6f85
to
610e1a4
Compare
794d063
to
e92124d
Compare
/// adherence with PEP 723. | ||
#[arg( | ||
long, | ||
conflicts_with = "active", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to allow active e.g. for uv sync --script --active scripts/publish/test_publish.py
? My use case is getting IDE support without explicit uv IDE support, having a shortcut for uv export --script scripts/publish/test_publish.py | uv pip install -
. (I remember we had a discussion about that, but i can't find it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I sort of defer to @zanieb here because it could cause complications if we ever want to allow "run a script in the context of a project".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"run a script in the context of a project".
Can you describe what this means briefly? Layered on top of the project environment?
I think --active
makes sense here. I presume it's awkward to support given how I implemented --active
though?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think --active
wouldn't be too bad to support. I thought there was some thought that we might want you to be able to "run a script in the context of a project" -- I don't know what it means exactly, but there's some vague allusions to it in the code. Maybe, like, layering the script's dependencies atop the project's dependencies (like you said)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we... warn, if VIRTUAL_ENV
is set but the user didn't provide --active
(following projects)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did this separately: #11433
VirtualProject::NonProject(workspace) => DependencyGroupsTarget::Workspace(workspace), | ||
}; | ||
target.validate(&dev)?; | ||
SyncTarget::Script(_) => {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
uv sync --group foo --script scripts/publish/test_publish.py
passes without warnings, is that intended? Same for --extra
, both are banned by uv run
.
With syncing support there's new a cause for groups in scripts (say a lint group that requires ruff because you want to format and lint the script), but i assume that discussion is for later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They should be banned. Groups and extras are not supported in scripts — they’re not in the standard.
r"environments-v1/script-\w+", | ||
"environments-v1/script-[HASH]", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add this filter to the test context, given that it's an unstable part of stderr for this workflow?
It's pretty surprising that it does this, given it's otherwise opt-in. I'm hesitant to ask you to do more work, but... Is there a reason it's that way — other than it being the easier implementation? |
I can change it, it will just be a lot more code, since it requires |
It's not a lot of work, it's just a lot more code (plus some test coverage). |
Yeah that stinks... I think we should only change it if we want to take a firmer stance on scripts having lockfiles? The part that bothers me is that we'd create one on |
Sounds good -- I think I should just change it to be consistent with |
610e1a4
to
ad3294b
Compare
e92124d
to
4a1e9f7
Compare
8614745
to
d810803
Compare
4a1e9f7
to
d404d8f
Compare
Updated the PR to avoid creating a lockfile if it doesn't already exist. |
dc808ba
to
c60b315
Compare
#[arg( | ||
long, | ||
conflicts_with = "active", | ||
conflicts_with = "all_packages", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You know conflicts_with_all
exists, right? :)
crates/uv-cli/src/lib.rs
Outdated
/// Sync the virtual environment for the specified PEP 723 Python script, rather than the current | ||
/// project. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor preference to keep this on one line for brevity / readability in the CLI short help.
c60b315
to
c480945
Compare
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [astral-sh/uv](https://github.com/astral-sh/uv) | patch | `0.5.30` -> `0.5.31` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>astral-sh/uv (astral-sh/uv)</summary> ### [`v0.5.31`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#0531) [Compare Source](astral-sh/uv@0.5.30...0.5.31) ##### Enhancements - Add `uv sync --script` ([#​11361](astral-sh/uv#11361)) - Allow PEP 508 requirements in tool requests ([#​11337](astral-sh/uv#11337)) - Allow source distributions to produce wheels with `+local` suffixes ([#​11429](astral-sh/uv#11429)) - Bring parity to `uvx` and `uv tool install` requests ([#​11345](astral-sh/uv#11345)) - Use a stable directory for local, remote, and stdin script virtual environments ([#​11347](astral-sh/uv#11347), [#​11364](astral-sh/uv#11364)) - Detect infinite recursion in `uv run` ([#​11386](astral-sh/uv#11386)) ##### Python The managed Python distributions have been updated, including: - CPython 3.14.0a5, which includes a new [tail calling interpreter](https://docs.python.org/3.14/whatsnew/3.14.html#whatsnew314-tail-call) for a significant performance improvement - The bundled OpenSSL version was updated from 3.0.15 to 3.0.16 which fixes a [security advisory](https://openssl-library.org/news/secadv/20241016.txt) See the [`python-build-standalone` release notes](https://github.com/astral-sh/python-build-standalone/releases/tag/20250212) for more details. ##### Bug fixes - Fix cross-drive script installation ([#​11167](astral-sh/uv#11167)) - Add indexes in priority order ([#​11451](astral-sh/uv#11451)) - Allow `--python <dir>` requests to match existing environments if `sys.executable` is the same file ([#​11290](astral-sh/uv#11290)) - Avoid comparing to system site packages in `--dry-run` mode ([#​11427](astral-sh/uv#11427)) - Prefer running executables in the environment with `<name>` over `<name>/__main__.py` ([#​11431](astral-sh/uv#11431)) - Retry local clones without hardlinks if they fail ([#​11421](astral-sh/uv#11421)) ##### Documentation - Update alternative-indexes.md to use `UV_INDEX` instead of `UV_EXTRA_INDEX_URL` ([#​11381](astral-sh/uv#11381)) - Update scripts guide to include using package indexes ([#​11443](astral-sh/uv#11443)) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xNjYuMSIsInVwZGF0ZWRJblZlciI6IjM5LjE2Ni4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
## Summary See: #11361 (comment)
Summary
The environment is located at a stable path within the cache, based on the script's absolute path.
If a lockfile exists for the script, then we use our standard lockfile semantics (i.e., update the lockfile if necessary, etc.); if not, we just do a
uv pip sync
(roughly).Example usage:
Closes #6637.