Commit Graph

15 Commits

Author SHA1 Message Date
Aria Desires 5021840919
Add `[tool.uv.dependency-groups].mygroup.requires-python` (#13735)
This allows you to specify requires-python on individual dependency-groups,
with the intended usecase being "oh my dev-dependencies have a higher
requires-python than my actual project".

This includes a large driveby move of the RequiresPython type to
uv-distribution-types to allow us to generate the appropriate markers at
this point in the code. It also migrates RequiresPython from
pubgrub::Range to version_ranges::Ranges, and makes several pub(crate)
items pub, as it's no longer defined in uv_resolver.

Fixes #11606
2025-06-13 22:04:13 +00:00
konsti e843433b07
Cache workspace discovery (#12096)
Reduce the overhead of `uv run` in large workspaces. Instead of
re-discovering the entire workspace each time we resolve the metadata of
a member, we can the discovered set of workspace members. Care needs to
be taken to not cache the discovery for `uv init`, `uv add` and `uv
remove`, which change the definitions of workspace members.

Below is apache airflow e3fe06382df4b19f2c0de40ce7c0bdc726754c74 `uv run
python` with a minimal payload. With this change, we avoid a ~350ms
overhead of each `uv run` invocation.

```
$ hyperfine --warmup 2 \
    "uv run --no-dev python -c \"print('hi')\"" \
    "uv-profiling run --no-dev python -c \"print('hi')\""
Benchmark 1: uv run --no-dev python -c "print('hi')"
  Time (mean ± σ):     492.6 ms ±   7.0 ms    [User: 393.2 ms, System: 97.1 ms]
  Range (min … max):   482.3 ms … 501.5 ms    10 runs
 
Benchmark 2: uv-profiling run --no-dev python -c "print('hi')"
  Time (mean ± σ):     129.7 ms ±   2.5 ms    [User: 105.4 ms, System: 23.2 ms]
  Range (min … max):   126.0 ms … 136.1 ms    22 runs
 
Summary
  uv-profiling run --no-dev python -c "print('hi')" ran
    3.80 ± 0.09 times faster than uv run --no-dev python -c "print('hi')"
```

The profile after those change below. We still spend a large chunk in
toml parsing (both `uv.lock` and `pyproject.toml`), but it's not
excessive anymore.


![image](https://github.com/user-attachments/assets/6fe78510-7e25-48ee-8a6d-220ee98ad120)
2025-03-10 22:03:30 +01:00
Micha Reiser 7b4197bc0e
Detect nested workspace inside the current workspace and members with identical names (#9094)
## Summary

Align uv's workspace discovery with red knots (see
https://github.com/astral-sh/ruff/pull/14308#issuecomment-2474296308)

* Detect nested workspace inside the current workspace rather than
testing if the current workspace is a member of any outer workspace.
* Detect packages with identical names.

## Test Plan

I added two integration tests. I also back ported the tests to main to
verify that both these invalid workspaces aren't catched by uv today.
That makes this, technically, a breaking change but I would consider the
change a bug fix.

---------

Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
2024-11-15 04:03:00 +00:00
Charlie Marsh d3e50a2376
Enable `--all-packages --frozen` in `uv sync` and `uv export` (#8760)
## Summary

This PR improves the interaction of `--frozen` such that we reduce the
dependency on the `pyproject.toml` and increase the dependency on the
`uv.lock`. Specifically, we now read the list of workspace members from
the `uv.lock` rather than the `pyproject.toml`, which means we don't
need to discover the member `pyproject.toml` files in order to perform a
`uv sync --frozen --all-packages`.
2024-11-02 02:48:55 +00:00
Charlie Marsh dd0f696695
Allow `[dependency-groups]` in non-`[project]` projects (#8574)
## Summary

We already support `tool.uv.dev-dependencies` in the legacy
non-`[project]` projects. This adds equivalent support for
`[dependency-groups]`, e.g.:

```toml
[tool.uv.workspace]

[dependency-groups]
lint = ["ruff"]
```
2024-10-25 13:57:06 -05:00
Charlie Marsh f9c04581e6
Allow `uv sync --package` without copying member `pyproject.toml` (#6943)
## Summary

Closes https://github.com/astral-sh/uv/issues/6935.
2024-09-02 21:01:50 +00:00
Charlie Marsh 53ef633c6d
Do not require workspace members to sync with `--frozen` (#6737)
## Summary

Closes https://github.com/astral-sh/uv/issues/6685.
2024-08-28 07:58:50 -04:00
Charlie Marsh 1ae2c3f142
Respect `tool.uv.environments` in `pip compile --universal` (#6663)
## Summary

We now respect the `environments` field in `uv pip compile --universal`,
e.g.:

```toml
[tool.uv]
environments = ["platform_system == 'Emscripten'"]
```

Closes https://github.com/astral-sh/uv/issues/6641.
2024-08-26 23:58:17 +00:00
Charlie Marsh 3395d24959
Allow user to constrain supported lock environments (#6210)
## Summary

The strategy here is: if the user provides supported environments, we
use those as the initial forks when resolving. As a result, we never add
or explore branches that are disjoint with the supported environments.
(If the supported environments change, we ignore the lockfile entirely,
so we don't have to worry about any interactions between supported
environments and the preference forks.)

Closes https://github.com/astral-sh/uv/issues/6184.
2024-08-20 13:28:04 +00:00
Jo 7bcafec778
Add `uv init --virtual` (#5396)
## Summary

Add `uv init --virtual` to create an explicit virtual workspace.

Relates to #5338
2024-07-24 18:52:33 +00:00
Charlie Marsh 0f8186d9ad
Add `requires-python` to `uv init` (#5322)
## Summary

Prefers, in order:

- The major-minor version of an interpreter discovered via `--python`.
- The `requires-python` from the workspace.
- The major-minor version of the default interpreter.

If the `--python` request is a version or a version range, we use that
without fetching an interpreter.

Closes https://github.com/astral-sh/uv/issues/5299.
2024-07-23 16:02:40 +00:00
Charlie Marsh 841edc3718
Move workspace abstractions to `uv-workspace` crate (#5236)
## Summary

These are really different from the rest of the existing crate as
evidenced by the bifurcation in the requirements.
2024-07-20 02:15:32 +00:00
Charlie Marsh cacd1a2b5a
Load configuration options from workspace root (#4295)
## Summary

In a workspace, we now read configuration from the workspace root.
Previously, we read configuration from the first `pyproject.toml` or
`uv.toml` file in path -- but in a workspace, that would often be the
_project_ rather than the workspace configuration.

We need to read configuration from the workspace root, rather than its
members, because we lock the workspace globally, so all configuration
applies to the workspace globally.

As part of this change, the `uv-workspace` crate has been renamed to
`uv-settings` and its purpose has been narrowed significantly (it no
longer discovers a workspace; instead, it just reads the settings from a
directory).

If a user has a `uv.toml` in their directory or in a parent directory
but is _not_ in a workspace, we will still respect that use-case as
before.

Closes #4249.
2024-06-14 01:26:20 +00:00
Charlie Marsh 1aa8ff8268
Merge user and workspace settings (#3462)
## Summary

This PR follows Cargo's strategy for merging configuration, albeit in a
more limited way (we don't support as many configuration locations).
Specifically, we merge the user configuration with the workspace
configuration if both are present. The workspace configuration has
priority, such that we take values from the workspace configuration and
ignore those in the user configuration if both are specified for a given
setting -- with the exception of arrays and maps, which are
concatenated.

For now, if a user provides a configuration file with `--config-file`,
we _don't_ merge in the user settings.

See:
https://doc.rust-lang.org/cargo/reference/config.html#hierarchical-structure.

Closes #3420.
2024-05-08 14:49:43 -04:00
Charlie Marsh 295b58ad37
Add `uv-workspace` crate with settings discovery and deserialization (#3007)
## Summary

This PR adds basic struct definitions along with a "workspace" concept
for discovering settings. (The "workspace" terminology is used to match
Ruff; I did not invent it.)

A few notes:

- We discover any `pyproject.toml` or `uv.toml` file in any parent
directory of the current working directory. (We could adjust this to
look at the directories of the input files.)
- We don't actually do anything with the configuration yet; but those
PRs are large and I want this to be reviewed in isolation.
2024-04-16 13:56:47 -04:00