165 Commits

Author	SHA1	Message	Date
konsti	0010954ca7	Add parsed URL to `PubGrubPackage` (#3426) ... Avoid reparsing urls by storing the parsed parts across resolution on `PubGrubPackage`. Part 1 of #3408	2024-05-14 00:55:21 +00:00
Charlie Marsh	8cec217eff	Avoid attempting to build editables when fetching metadata (#3563) ... ## Summary If we see an editable as a dependency, we currently attempt to fetch its metadata, when we shouldn't. Closes https://github.com/astral-sh/uv/issues/3562.	2024-05-14 00:03:53 +00:00
Charlie Marsh	44363d25c2	Respect constraints on editable dependencies (#3554) ... ## Summary Ensures that constraints are enforced for editable requirements. Closes #3548.	2024-05-13 17:06:27 +00:00
Charlie Marsh	eb8e733790	Rename "constraints" to "dependencies" in resolver (#3552) ... ## Summary It's confusing that we use `constraints` here because constraints mean something else for us (e.g., `--constraint constraints.txt`). These are really the dependencies of a given `PubGrubPackage` -- the type is even called `PubGrubDependencies`.	2024-05-13 16:30:16 +00:00
Charlie Marsh	42c3bfa351	Make `Directory` its own distribution kind (#3519) ... ## Summary I think this is overall good change because it explicitly encodes (in the type system) something that was previously implicit. I'm not a huge fan of the names here, open to input. It covers some of https://github.com/astral-sh/uv/issues/3506 but I don't think it _closes_ it.	2024-05-13 10:03:14 -04:00
Dimitri Papadopoulos Orfanos	d2ee567fe7	Fix a few typos found by codespell (#3543) ... <!-- Thank you for contributing to uv! To help us out with reviewing, please consider the following: - Does this pull request include a summary of the change? (See below.) - Does this pull request include a descriptive title? - Does this pull request include references to any relevant issues? --> ## Summary Just fix typos. While `alpha-numeric` is not really a misspelling: - it is missing from mainstream curated dictionaries, all of them suggest `alphanumeric`; - it is less used than `alphanumeric` (more than ⨉10 less) according to the Google [Ngram Viewer](https://books.google.com/ngrams/graph?content=alpha-numeric%2Calphanumeric&year_start=1900&year_end=2019&corpus=en-2019); - it is [missing from SCOWL](http://app.aspell.net/lookup?dict=en_US-large;words=alpha-numeric). ## Test Plan CI jobs.	2024-05-13 11:55:10 +00:00
Ibraheem Ahmed	783df8f657	Consolidate concurrency limits (#3493) ... ## Summary This PR consolidates the concurrency limits used throughout `uv` and exposes two limits, `UV_CONCURRENT_DOWNLOADS` and `UV_CONCURRENT_BUILDS`, as environment variables. Currently, `uv` has a number of concurrent streams that it buffers using relatively arbitrary limits for backpressure. However, many of these limits are conflated. We run a relatively small number of tasks overall and should start most things as soon as possible. What we really want to limit are three separate operations: - File I/O. This is managed by tokio's blocking pool and we should not really have to worry about it. - Network I/O. - Python build processes. Because the current limits span a broad range of tasks, it's possible that a limit meant for network I/O is occupied by tasks performing builds, reading from the file system, or even waiting on a `OnceMap`. We also don't limit build processes that end up being required to perform a download. While this may not pose a performance problem because our limits are relatively high, it does mean that the limits do not do what we want, making it tricky to expose them to users (https://github.com/astral-sh/uv/issues/1205, https://github.com/astral-sh/uv/issues/3311). After this change, the limits on network I/O and build processes are centralized and managed by semaphores. All other tasks are unbuffered (note that these tasks are still bounded, so backpressure should not be a problem).	2024-05-10 12:43:08 -04:00
Andrew Gallant	ad01a768bc	uv-resolver: push resolver state to its own type (#3492) ... This still keeps the resolver state on the stack, but it organizes it into a more structured representation. This is a precursor to implementing resolver forking, where we will ultimately put this state on the heap. The idea is that this will let us maintain multiple independent resolver states that will all produce their own resolution (and potentially other forked states). Closes #3354	2024-05-09 14:16:43 -04:00
Andrew Gallant	8b0fad3560	uv-resolver: make MarkerEnvironment optional ... This commit touches a lot of code, but the conceptual change here is pretty simple: make it so we can run the resolver without providing a `MarkerEnvironment`. This also indicates that the resolver should run in universal mode. That is, the effect of a missing marker environment is that all marker expressions that reference the marker environment are evaluated to `true`. That is, they are ignored. (The only markers we evaluate in that context are extras, which are the only markers that aren't dependent on the environment.) One interesting change here is that a `Resolver` no longer needs an `Interpreter`. Previously, it had only been using it to construct a `PythonRequirement`, by filling in the installed version from the `Interpreter` state. But we now construct a `PythonRequirement` explicitly since its `target` Python version should no longer be tied to the `MarkerEnvironment`. (Currently, the marker environment is mutated such that its `python_full_version` is derived from multiple sources, including the CLI, which I found a touch confusing.) The change in behavior can now be observed through the `--unstable-uv-lock-file` flag. First, without it: ``` $ cat requirements.in anyio>=4.3.0 ; sys_platform == "linux" anyio<4 ; sys_platform == "darwin" $ cargo run -qp uv -- pip compile -p3.10 requirements.in anyio==4.3.0 exceptiongroup==1.2.1 # via anyio idna==3.7 # via anyio sniffio==1.3.1 # via anyio typing-extensions==4.11.0 # via anyio ``` And now with it: ``` $ cargo run -qp uv -- pip compile -p3.10 requirements.in --unstable-uv-lock-file x No solution found when resolving dependencies: `-> Because you require anyio>=4.3.0 and anyio<4, we can conclude that the requirements are unsatisfiable. ``` This is expected at this point because the marker expressions are being explicitly ignored, *and* there is no forking done yet to account for the conflict.	2024-05-09 09:24:37 -04:00
konsti	1ad6aa8a23	Use generic pubgrub incompatibility reason (#3335) ... Pubgrub got a new feature where all unavailability is a custom, instead of the reasonless `UnavailableDependencies` and our custom `String` type previously (https://github.com/pubgrub-rs/pubgrub/pull/208). This PR introduces a `UnavailableReason` that tracks either an entire version being unusable, or a specific version. The error messages now also track this difference properly. The pubgrub commit is our main rebased onto the merged https://github.com/pubgrub-rs/pubgrub/pull/208, i'll push `konsti/main-rebase-generic-reason` to `main` after checking for rebase problems.	2024-05-08 08:40:15 +00:00
Ibraheem Ahmed	94cf604574	Remove unnecessary uses of `DashMap` and `Arc` (#3413) ... ## Summary All of the resolver code is run on the main thread, so a lot of the `Send` bounds and uses of `DashMap` and `Arc` are unnecessary. We could also switch to using single-threaded versions of `Mutex` and `Notify` in some places, but there isn't really a crate that provides those I would be comfortable with using. The `Arc` in `OnceMap` can't easily be removed because of the uv-auth code which uses the [reqwest-middleware](https://docs.rs/reqwest-middleware/latest/reqwest_middleware/trait.Middleware.html) crate, that seems to adds unnecessary `Send` bounds because of `async-trait`. We could duplicate the code and create a `OnceMapLocal` variant, but I don't feel that's worth it.	2024-05-06 22:30:43 -04:00
konsti	2c84af15b8	Rename `distribution_types::VersionOrUrl` to `VersionOrUrlRef` (#3254) ... This is more consistent with the other `*Ref` types and reduces confusion with the real `VersionOrUrl` type.	2024-05-06 14:15:56 -04:00
konsti	098944fc7d	Improve non-git error message (#3403) ... The boxing changes are due to clippy	2024-05-06 13:28:05 +02:00
konsti	9de49c8a60	Make pubgrub an allowed ident (#3399) ... Followup to #3361, fix some backtick-quoting.	2024-05-06 09:10:37 +00:00
konsti	4f87edbe66	Add basic `tool.uv.sources` support (#3263) ... ## Introduction PEP 621 is limited. Specifically, it lacks * Relative path support * Editable support * Workspace support * Index pinning or any sort of index specification The semantics of urls are a custom extension, PEP 440 does not specify how to use git references or subdirectories, instead pip has a custom stringly format. We need to somehow support these while still stying compatible with PEP 621. ## `tool.uv.source` Drawing inspiration from cargo, poetry and rye, we add `tool.uv.sources` or (for now stub only) `tool.uv.workspace`: ```toml [project] name = "albatross" version = "0.1.0" dependencies = [ "tqdm >=4.66.2,<5", "torch ==2.2.2", "transformers[torch] >=4.39.3,<5", "importlib_metadata >=7.1.0,<8; python_version < '3.10'", "mollymawk ==0.1.0" ] [tool.uv.sources] tqdm = { git = "https://github.com/tqdm/tqdm", rev = "cc372d09dcd5a5eabdc6ed4cf365bdb0be004d44" } importlib_metadata = { url = "https://github.com/python/importlib_metadata/archive/refs/tags/v7.1.0.zip" } torch = { index = "torch-cu118" } mollymawk = { workspace = true } [tool.uv.workspace] include = [ "packages/mollymawk" ] [tool.uv.indexes] torch-cu118 = "https://download.pytorch.org/whl/cu118" ``` See `docs/specifying_dependencies.md` for a detailed explanation of the format. The basic gist is that `project.dependencies` is what ends up on pypi, while `tool.uv.sources` are your non-published additions. We do support the full range or PEP 508, we just hide it in the docs and prefer the exploded table for easier readability and less confusing with actual url parts. This format should eventually be able to subsume requirements.txt's current use cases. While we will continue to support the legacy `uv pip` interface, this is a piece of the uv's own top level interface. Together with `uv run` and a lockfile format, you should only need to write `pyproject.toml` and do `uv run`, which generates/uses/updates your lockfile behind the scenes, no more pip-style requirements involved. It also lays the groundwork for implementing index pinning. ## Changes This PR implements: * Reading and lowering `project.dependencies`, `project.optional-dependencies` and `tool.uv.sources` into a new requirements format, including: * Git dependencies * Url dependencies * Path dependencies, including relative and editable * `pip install` integration * Error reporting for invalid `tool.uv.sources` * Json schema integration (works in pycharm, see below) * Draft user-level docs (see `docs/specifying_dependencies.md`) It does not implement: * No `pip compile` testing, deprioritizing towards our own lockfile * Index pinning (stub definitions only) * Development dependencies * Workspace support (stub definitions only) * Overrides in pyproject.toml * Patching/replacing dependencies One technically breaking change is that we now require user provided pyproject.toml to be valid wrt to PEP 621. Included files still fall back to PEP 517. That means `pip install -r requirements.txt` requires it to be valid while `pip install -r requirements.txt` with `-e .` as content falls back to PEP 517 as before. ## Implementation The `pep508` requirement is replaced by a new `UvRequirement` (name up for bikeshedding, not particularly attached to the uv prefix). The still existing `pep508_rs::Requirement` type is a url format copied from pip's requirements.txt and doesn't appropriately capture all features we want/need to support. The bulk of the diff is changing the requirement type throughout the codebase. We still use `VerbatimUrl` in many places, where we would expect a parsed/decomposed url type, specifically: * Reading core metadata except top level pyproject.toml files, we fail a step later instead if the url isn't supported. * Allowed `Urls`. * `PackageId` with a custom `CanonicalUrl` comparison, instead of canonicalizing urls eagerly. * `PubGrubPackage`: We eventually convert the `VerbatimUrl` back to a `Dist` (`Dist::from_url`), instead of remembering the url. * Source dist types: We use verbatim url even though we know and require that these are supported urls we can and have parsed. I tried to make improve the situation be replacing `VerbatimUrl`, but these changes would require massive invasive changes (see e.g. https://github.com/astral-sh/uv/pull/3253). A main problem is the ref `VersionOrUrl` and applying overrides, which assume the same requirement/url type everywhere. In its current form, this PR increases this tech debt. I've tried to split off PRs and commits, but the main refactoring is still a single monolith commit to make it compile and the tests pass. ## Demo Adding d1ae3b85d5/pyproject.json as json schema (v7) to pycharm for `pyproject.toml`, you can try the IDE support already:  [dove.webm](https://github.com/astral-sh/uv/assets/6826232/c293c272-c80b-459d-8c95-8c46a8d198a1)	2024-05-03 21:10:50 +00:00
Andrew Gallant	0b84eb0140	once-map: avoid hard-coding `Arc` (#3242) ... The only thing a `OnceMap` really needs to be able to do with the value is to clone it. All extant uses benefited from having this done for them by automatically wrapping values in an `Arc`. But this isn't necessarily true for all things. For example, a value might have an `Arc` internally to making cloning cheap in other contexts, and it doesn't make sense to re-wrap it in an `Arc` just to use it with a `OnceMap`. Or alternatively, cloning might just be cheap enough on its own that an `Arc` isn't worth it.	2024-04-24 11:11:46 -04:00
Charlie Marsh	792a917a97	Restrict observed requirements to direct when `--no-deps` is specified (#3191) ... ## Summary This PR avoids: (1) using the lookahead resolver when `--no-deps` is specified (we'll never use those requirements), and (2) including any transitive requirements when searching for allowed URLs, etc., when `--no-deps` is specified. Closes https://github.com/astral-sh/uv/issues/3183.	2024-04-22 17:17:58 +00:00
Charlie Marsh	a4f125ca34	Avoid waiting for metadata for `--no-deps` editables (#3188) ... ## Summary We don't emit a request for this, so we shouldn't wait for it either -- we already have the metadata! Closes https://github.com/astral-sh/uv/issues/3184.	2024-04-22 16:29:19 +00:00
Charlie Marsh	a241bc79b1	Add priorities for editables (#3133) ... ## Summary We weren't setting a priority for editables, so they were being visited last. I think there's still a problem whereby we're not aggressive enough in visiting recursive extras (and, in fact, that's making it really hard to write a test -- I wrote a test, but the most-reduced case still fails, and I'd need to add a layer of indirection to make it fail-on-main-but-pass-on-this-branch), but that problem likely already existed on main prior to #3087, so I just want to get this quick fix out now. Closes https://github.com/astral-sh/uv/issues/3127. ## Test Plan - `git clone https://github.com/cda-tum/mqt-core.git` - `cargo run venv` - `cargo run pip install 'scikit-build-core[pyproject]>=0.8.1' 'setuptools_scm>=7' 'pybind11>=2.12' --resolution=lowest-direct` - `cargo run pip install --no-build-isolation '-ve.[test,qiskit,evaluation,coverage]' --resolution=lowest-direct`	2024-04-19 02:04:58 +00:00
Charlie Marsh	2e88bb6f1b	Add a proxy layer for extras (#3100) ... Given requirements like: ``` black==23.1.0 black[colorama] ``` The resolver will (on `main`) add a dependency on Black, and then try to use the most recent version of Black to satisfy `black[colorama]`. For sake of example, assume `black==24.0.0` is the most recent version. Once the selects this most recent version, it'll fetch the metadata, then return the dependencies for `black==24.0.0` with the `colorama` extra enabled. Finally, it will tack on `black==24.0.0` (a dependency on the base package). The resolver will then detect a conflict between `black==23.1.0` and `black==24.0.0`, and throw out `black[colorama]==24.0.0`, trying to next most-recent version. This is both wasteful and can cause problems, since we're fetching metadata for versions that will _never_ satisfy the resolver. In the `apache-airflow[all]` case, I also ran into an issue whereby we were attempting to build very old versions of `apache-airflow` due to `apache-airflow[pandas]`, which in turn led to resolution failures. The solution proposed here is that we create a new proxy package with exactly two dependencies: one on `black` and one of `black[colorama]`. Both of these packages must be at the same version as the proxy package, so the resolver knows much _earlier_ that (in the above example) the extra variant _must_ match `23.1.0`.	2024-04-19 01:04:59 +00:00
Charlie Marsh	b456fa2939	Incorporate heuristics to improve package prioritization (#3087) ... See: https://github.com/astral-sh/uv/issues/3078	2024-04-17 14:21:42 +00:00
konsti	d1b07a3f49	Log versions tried from batch prefetch (#3090) ... This is required for evaluating #3087. This also removes tracking of virtual packages from extras from the batch prefetcher (we only track real packages). Let's look at some stats: * jupyter: Tried 100 versions: anyio 1, argon2-cffi 1, argon2-cffi-bindings 1, arrow 1, asttokens 1, async-lru 1, attrs 1, babel 1, beautifulsoup4 1, bleach 1, certifi 1, cffi 1, charset-normalizer 1, comm 1, debugpy 1, decorator 1, defusedxml 1, exceptiongroup 1, executing 1, fastjsonschema 1, fqdn 1, h11 1, httpcore 1, httpx 1, idna 1, ipykernel 1, ipython 1, ipywidgets 1, isoduration 1, jedi 1, jinja2 1, json5 1, jsonpointer 1, jsonschema 1, jsonschema-specifications 1, jupyter 1, jupyter-client 1, jupyter-console 1, jupyter-core 1, jupyter-events 1, jupyter-lsp 1, jupyter-server 1, jupyter-server-terminals 1, jupyterlab 1, jupyterlab-pygments 1, jupyterlab-server 1, jupyterlab-widgets 1, markupsafe 1, matplotlib-inline 1, mistune 1, nbclient 1, nbconvert 1, nbformat 1, nest-asyncio 1, notebook 1, notebook-shim 1, overrides 1, packaging 1, pandocfilters 1, parso 1, pexpect 1, platformdirs 1, prometheus-client 1, prompt-toolkit 1, psutil 1, ptyprocess 1, pure-eval 1, pycparser 1, pygments 1, python-dateutil 1, python-json-logger 1, pyyaml 1, pyzmq 1, qtconsole 1, qtpy 1, referencing 1, requests 1, rfc3339-validator 1, rfc3986-validator 1, root 1, rpds-py 1, send2trash 1, six 1, sniffio 1, soupsieve 1, stack-data 1, terminado 1, tinycss2 1, tomli 1, tornado 1, traitlets 1, types-python-dateutil 1, typing-extensions 1, uri-template 1, urllib3 1, wcwidth 1, webcolors 1, webencodings 1, websocket-client 1, widgetsnbextension 1 * boto3: botocore 1697, boto3 849, urllib3 2, jmespath 1, python-dateutil 1, root 1, s3transfer 1, six 1 * transformers-extras: Tried 1191 versions: sagemaker 152, hypothesis 67, tensorflow 21, jsonschema 19, tensorflow-cpu 18, multiprocess 10, pathos 10, tensorflow-text 10, chex 8, tf-keras 8, tf2onnx 8, aiohttp 6, aiosignal 6, alembic 6, annotated-types 6, apscheduler 6, attrs 6, backoff 6, binaryornot 6, black 6, boto3 6, click 6, coloredlogs 6, colorlog 6, dash 6, dash-bootstrap-components 6, dlinfo 6, exceptiongroup 6, execnet 6, fire 6, frozenlist 6, gitdb 6, google-auth 6, google-auth-oauthlib 6, hjson 6, iniconfig 6, jinja2-time 6, markdown 6, markdown-it-py 6, markupsafe 6, mpmath 6, namex 6, nbformat 6, ninja 6, nvidia-nvjitlink-cu12 6, onnxconverter-common 6, pandas 6, plac 6, platformdirs 6, pluggy 6, portalocker 6, poyo 6, protobuf3-to-dict 6, py-cpuinfo 6, py3nvml 6, pyarrow 6, pyarrow-hotfix 6, pydantic-core 6, pygments 6, pynvml 6, pypng 6, python-slugify 6, responses 6, smdebug-rulesconfig 6, soupsieve 6, sqlalchemy 6, tensorboard-data-server 6, tensorboard-plugin-wit 6, tensorboardx 6, threadpoolctl 6, tomli 6, wasabi 6, wcwidth 6, werkzeug 6, wheel 6, xxhash 6, zipp 6, etils 5, tensorboard 5, beautifulsoup4 4, cffi 4, clldutils 4, codecarbon 4, datasets 4, dill 4, evaluate 4, gitpython 4, hf-doc-builder 4, kenlm 4, librosa 4, llvmlite 4, nest-asyncio 4, nltk 4, optuna 4, parameterized 4, phonemizer 4, psutil 4, pyctcdecode 4, pytest 4, pytest-timeout 4, pytest-xdist 4, ray 4, rjieba 4, rouge-score 4, ruff 4, sacrebleu 4, sacremoses 4, sigopt 4, sortedcontainers 4, tensorstore 4, timeout-decorator 4, toolz 4, torchaudio 4, accelerate 3, audioread 3, cookiecutter 3, decorator 3, deepspeed 3, faiss-cpu 3, flax 3, fugashi 3, ipadic 3, isort 3, jax 3, jaxlib 3, joblib 3, keras-nlp 3, lazy-loader 3, numba 3, optax 3, pooch 3, pydantic 3, pygtrie 3, rhoknp 3, scikit-learn 3, segments 3, soundfile 3, soxr 3, sudachidict-core 3, sudachipy 3, torch 3, unidic 3, unidic-lite 3, urllib3 3, absl-py 2, arrow 2, astunparse 2, async-timeout 2, botocore 2, cachetools 2, certifi 2, chardet 2, charset-normalizer 2, csvw 2, dash-core-components 2, dash-html-components 2, dash-table 2, diffusers 2, dm-tree 2, fastjsonschema 2, flask 2, flatbuffers 2, fsspec 2, ftfy 2, gast 2, google-pasta 2, greenlet 2, grpcio 2, h5py 2, humanfriendly 2, idna 2, importlib-metadata 2, importlib-resources 2, jinja2 2, jmespath 2, jupyter-core 2, kagglehub 2, keras 2, keras-core 2, keras-preprocessing 2, libclang 2, mako 2, mdurl 2, ml-dtypes 2, msgpack 2, multidict 2, mypy-extensions 2, networkx 2, nvidia-cublas-cu12 2, nvidia-cuda-cupti-cu12 2, nvidia-cuda-nvrtc-cu12 2, nvidia-cuda-runtime-cu12 2, nvidia-cudnn-cu12 2, nvidia-cufft-cu12 2, nvidia-curand-cu12 2, nvidia-cusolver-cu12 2, nvidia-cusparse-cu12 2, nvidia-nccl-cu12 2, nvidia-nvtx-cu12 2, onnx 2, onnxruntime 2, onnxruntime-tools 2, opencv-python 2, opt-einsum 2, orbax-checkpoint 2, pathspec 2, plotly 2, pox 2, ppft 2, pyasn1-modules 2, pycparser 2, pyrsistent 2, python-dateutil 2, pytz 2, requests-oauthlib 2, retrying 2, rich 2, rsa 2, s3transfer 2, scipy 2, setuptools 2, six 2, smmap 2, sympy 2, tabulate 2, tensorflow-estimator 2, tensorflow-hub 2, tensorflow-io-gcs-filesystem 2, termcolor 2, text-unidecode 2, traitlets 2, triton 2, typing-extensions 2, tzdata 2, tzlocal 2, wrapt 2, xmltodict 2, yarl 2, Python 1, av 1, babel 1, bibtexparser 1, blinker 1, colorama 1, decord 1, filelock 1, huggingface-hub 1, isodate 1, itsdangerous 1, language-tags 1, lxml 1, numpy 1, oauthlib 1, packaging 1, pillow 1, protobuf 1, pyasn1 1, pylatexenc 1, pyparsing 1, pyyaml 1, rdflib 1, regex 1, requests 1, rfc3986 1, root 1, safetensors 1, sentencepiece 1, tenacity 1, timm 1, tokenizers 1, torchvision 1, tqdm 1, transformers 1, types-python-dateutil 1, uritemplate 1 You can reproduce them with python 3.10 and: ``` RUST_LOG=uv_resolver=debug cargo run pip compile -o /dev/null -q scripts/requirements/<input>.in 2>&1 | tail -n 1 ``` Closes #2270 - This is less invasive compared to the other PR, we can revisit number of network/build request tracking later.	2024-04-17 09:08:21 +00:00
Charlie Marsh	96c3c2e774	Support unnamed requirements in `--require-hashes` (#2993) ... ## Summary This PR enables `--require-hashes` with unnamed requirements. The key change is that `PackageId` becomes `VersionId` (since it refers to a package at a specific version), and the new `PackageId` consists of _either_ a package name _or_ a URL. The hashes are keyed by `PackageId`, so we can generate the `RequiredHashes` before we have names for all packages, and enforce them throughout. Closes #2979.	2024-04-11 11:26:50 -04:00
Charlie Marsh	006379c50c	Add support for URL requirements in `--generate-hashes` (#2952) ... ## Summary This PR enables hash generation for URL requirements when the user provides `--generate-hashes` to `pip compile`. While we include the hashes from the registry already, today, we omit hashes for URLs. To power hash generation, we introduce a `HashPolicy` abstraction: ```rust #[derive(Debug, Clone, Copy, PartialEq, Eq)] pub enum HashPolicy<'a> { /// No hash policy is specified. None, /// Hashes should be generated (specifically, a SHA-256 hash), but not validated. Generate, /// Hashes should be validated against a pre-defined list of hashes. If necessary, hashes should /// be generated so as to ensure that the archive is valid. Validate(&'a [HashDigest]), } ``` All of the methods on the distribution database now accept this policy, instead of accepting `&'a [HashDigest]`. Closes #2378.	2024-04-10 20:02:45 +00:00
Charlie Marsh	8513d603b4	Return computed hashes from metadata requests (#2951) ... ## Summary This PR modifies the distribution database to return both the `Metadata23` and the computed hashes when clients request metadata. No behavior changes, but this will be necessary to power `--generate-hashes`.	2024-04-10 19:31:41 +00:00
Charlie Marsh	1f3b5bb093	Add hash-checking support to `install` and `sync` (#2945) ... ## Summary This PR adds support for hash-checking mode in `pip install` and `pip sync`. It's a large change, both in terms of the size of the diff and the modifications in behavior, but it's also one that's hard to merge in pieces (at least, with any test coverage) since it needs to work end-to-end to be useful and testable. Here are some of the most important highlights: - We store hashes in the cache. Where we previously stored pointers to unzipped wheels in the `archives` directory, we now store pointers with a set of known hashes. So every pointer to an unzipped wheel also includes its known hashes. - By default, we don't compute any hashes. If the user runs with `--require-hashes`, and the cache doesn't contain those hashes, we invalidate the cache, redownload the wheel, and compute the hashes as we go. For users that don't run with `--require-hashes`, there will be no change in performance. For users that _do_, the only change will be if they don't run with `--generate-hashes` -- then they may see some repeated work between resolution and installation, if they use `pip compile` then `pip sync`. - Many of the distribution types now include a `hashes` field, like `CachedDist` and `LocalWheel`. - Our behavior is similar to pip, in that we enforce hashes when pulling any remote distributions, and when pulling from our own cache. Like pip, though, we _don't_ enforce hashes if a distribution is _already_ installed. - Hash validity is enforced in a few different places: 1. During resolution, we enforce hash validity based on the hashes reported by the registry. If we need to access a source distribution, though, we then enforce hash validity at that point too, prior to running any untrusted code. (This is enforced in the distribution database.) 2. In the install plan, we _only_ add cached distributions that have matching hashes. If a cached distribution is missing any hashes, or the hashes don't match, we don't return them from the install plan. 3. In the downloader, we _only_ return distributions with matching hashes. 4. The final combination of "things we install" are: (1) the wheels from the cache, and (2) the downloaded wheels. So this ensures that we never install any mismatching distributions. - Like pip, if `--require-hashes` is provided, we require that _all_ distributions are pinned with either `==` or a direct URL. We also require that _all_ distributions have hashes. There are a few notable TODOs: - We don't support hash-checking mode for unnamed requirements. These should be _somewhat_ rare, though? Since `pip compile` never outputs unnamed requirements. I can fix this, it's just some additional work. - We don't automatically enable `--require-hashes` with a hash exists in the requirements file. We require `--require-hashes`. Closes #474. ## Test Plan I'd like to add some tests for registries that report incorrect hashes, but otherwise: `cargo test`	2024-04-10 19:09:03 +00:00
Charlie Marsh	48ba7df98a	Move `FlatIndex` into the `uv-resolver` crate (#2972) ... ## Summary This lets us remove circular dependencies (in the future, e.g., #2945) that arise from `FlatIndex` needing a bunch of resolver-specific abstractions (like incompatibilities, required hashes, etc.) that aren't necessary to _fetch_ the flat index entries.	2024-04-10 14:38:42 -04:00
Charlie Marsh	c4472ebbb9	Enforce and backtrack on invalid versions in source metadata (#2954) ... ## Summary If we build a source distribution from the registry, and the version doesn't match that of the filename, we should error, just as we do for mismatched package names. However, we should also backtrack here, which we didn't previously. Closes https://github.com/astral-sh/uv/issues/2953. ## Test Plan Verified that `cargo run pip install docutils --verbose --no-cache --reinstall` installs `docutils==0.21` instead of the invalid `docutils==0.21.post1`. In the logs, I see: ``` WARN Unable to extract metadata for docutils: Package metadata version `0.21` does not match given version `0.21.post1` ```	2024-04-10 05:13:33 +00:00
Charlie Marsh	7ae06b3b46	Surface invalid metadata as hints in error reports (#2850) ... ## Summary Closes #2847.	2024-04-09 23:12:10 -04:00
Zanie Blue	1512e07a2e	Split configuration options out of `uv-types` (#2924) ... Needed to prevent circular dependencies in my toolchain work (#2931). I think this is probably a reasonable change as we move towards persistent configuration too? Unfortunately `BuildIsolation` needs to be in `uv-types` to avoid circular dependencies still. We might be able to resolve that in the future.	2024-04-09 11:35:53 -05:00
konsti	fb4ba2bbc2	Speed up cold cache urllib3/boto3/botocore with batched prefetching (#2452) ... With pubgrub being fast for complex ranges, we can now compute the next n candidates without taking a performance hit. This speeds up cold cache `urllib3<1.25.4` `boto3` from maybe 40s - 50s to ~2s. See docstrings for details on the heuristics. **Before**  **After**  --- We need two parts of the prefetching, first looking for compatible version and then falling back to flat next versions. After we selected a boto3 version, there is only one compatible botocore version remaining, so when won't find other compatible candidates for prefetching. We see this as a pattern where we only prefetch boto3 (stack bars), but not botocore (sequential requests between the stacked bars).  The risk is that we're completely wrong with the guess and cause a lot of useless network requests. I think this is acceptable since this mechanism only triggers when we're already on the bad path and we should simply have fetched all versions after some seconds (assuming a fast index like pypi). --- It would be even better if the pubgrub state was copy-on-write so we could simulate more progress than we actually have; currently we're guessing what the next version is which could be completely wrong, but i think this is still a valuable heuristic. Fixes #170.	2024-04-08 14:28:56 +00:00
Charlie Marsh	35940cb885	Remove additional 'because' (#2849) ... ## Summary Is this, perhaps, not totally necessary? It doesn't show up in any fixtures beyond those that I added recently. Closes https://github.com/astral-sh/uv/issues/2846.	2024-04-06 10:58:23 -04:00
Charlie Marsh	00934044aa	Backtrack on distributions with invalid metadata (#2834) ... ## Summary Closes https://github.com/astral-sh/uv/issues/2821.	2024-04-05 18:00:48 -04:00
Charlie Marsh	34341bd6e9	Allow package lookups across multiple indexes via explicit opt-in (#2815) ... ## Summary This partially revives https://github.com/astral-sh/uv/pull/2135 (with some modifications) to enable users to opt-in to looking for packages across multiple indexes. The behavior is such that, in version selection, we take _any_ compatible version from a "higher-priority" index over the compatible versions of a "lower-priority" index, even if that means we might accept an "older" version. Closes https://github.com/astral-sh/uv/issues/2775.	2024-04-03 23:23:37 +00:00
Charlie Marsh	189d0d41d0	Remove redirects from the resolver (#2792) ... ## Summary Rather than storing the `redirects` on the resolver, this PR just re-uses the "convert this URL to precise" logic when we convert to a `Resolution` after-the-fact. I think this is a lot simpler: it removes state from the resolver, and simplifies a lot of the hooks around distribution fetching (e.g., `get_or_build_wheel_metadata` no longer returns `(Metadata23, Option<Url>)`).	2024-04-03 02:43:57 +00:00
Charlie Marsh	999d653404	Use canonical URL to key redirect map (#2764) ... ## Summary This fixes a potential bug that revealed itself in https://github.com/astral-sh/uv/pull/2761. We don't run into this now because we always use "allowed URLs", stores the "last" compatible URL in the map. But the use of the "raw" URL (rather than the "canonical" URL) means that other writers have to follow that same assumption and iterate over dependencies in-order.	2024-04-01 17:57:13 -04:00
Charlie Marsh	8596ff3470	Remove `Cache` argument from `DistributionDatabase` (#2749) ... ## Summary We can access cache from `BuildContext`. This mirrors `SourceDistCachedBuilder`, which doesn't accept `Cache` as an argument and always accesses it through `BuildContext`.	2024-03-31 22:22:25 -04:00
Charlie Marsh	6d5b5ae9a2	Use distinct `Constraints` and `Overrides` types more widely (#2741) ... ## Summary No functional changes.	2024-03-31 13:46:37 -04:00
Zanie Blue	e1878c8359	Consider installed packages during resolution (#2596) ... Previously, we did not consider installed distributions as candidates while performing resolution. Here, we update the resolver to use installed distributions that satisfy requirements instead of pulling new distributions from the registry. The implementation details are as follows: - We now provide `SitePackages` to the `CandidateSelector` - If an installed distribution satisfies the requirement, we prefer it over remote distributions - We do not want to allow installed distributions in some cases, i.e., upgrade and reinstall - We address this by introducing an `Exclusions` type which tracks installed packages to ignore during selection - There's a new `ResolvedDist` wrapper with `Installed(InstalledDist)` and `Installable(Dist)` variants - This lets us pass already installed distributions throughout the resolver The user-facing behavior is thoroughly covered in the tests, but briefly: - Installing a package that depends on an already-installed package prefers the local version over the index - Installing a package with a name that matches an already-installed URL package does not reinstall from the index - Reinstalling (--reinstall) a package by name _will_ pull from the index even if an already-installed URL package is present - To reinstall the URL package, you must specify the URL in the request Closes https://github.com/astral-sh/uv/issues/1661 Addresses: - https://github.com/astral-sh/uv/issues/1476 - https://github.com/astral-sh/uv/issues/1856 - https://github.com/astral-sh/uv/issues/2093 - https://github.com/astral-sh/uv/issues/2282 - https://github.com/astral-sh/uv/issues/2383 - https://github.com/astral-sh/uv/issues/2560 ## Test plan - [x] Reproduction at `charlesnicholson/uv-pep420-bug` passes - [x] Unit test for editable package ([#1476](https://github.com/astral-sh/uv/issues/1476)) - [x] Unit test for previously installed package with empty registry - [x] Unit test for local non-editable package - [x] Unit test for new version available locally but not in registry ([#2093](https://github.com/astral-sh/uv/issues/2093)) - ~[ ] Unit test for wheel not available in registry but already installed locally ([#2282](https://github.com/astral-sh/uv/issues/2282))~ (seems complicated and not worthwhile) - [x] Unit test for install from URL dependency then with matching version ([#2383](https://github.com/astral-sh/uv/issues/2383)) - [x] Unit test for install of new package that depends on installed package does not change version ([#2560](https://github.com/astral-sh/uv/issues/2560)) - [x] Unit test that `pip compile` does _not_ consider installed packages	2024-03-28 13:49:17 -05:00
Charlie Marsh	b6ab919945	Make tags non-required for fetching wheel metadata (#2700) ... ## Summary This looks like a big change but it really isn't. Rather, I just split `get_or_build_wheel` into separate `get_wheel` and `build_wheel` methods internally, which made `get_or_build_wheel_metadata` capable of _not_ relying on `Tags`, which in turn makes it easier for us to use the `DistributionDatabase` in various places without having it coupled to an interpreter or environment (something we already did for `SourceDistributionBuilder`).	2024-03-28 00:06:25 +00:00
Zanie Blue	0b08ba1e67	Rename `uv-traits` and split into separate modules (#2674) ... This is driving me a little crazy and is becoming a larger problem in #2596 where I need to move more types (like `Upgrade` and `Reinstall`) into this crate. Anything that's shared across our core resolver, install, and build crates needs to be defined in this crate to avoid cyclic dependencies. We've outgrown it being a single file with some shared traits. There are no behavioral changes here.	2024-03-26 15:39:43 -05:00
Charlie Marsh	0ea51d43f5	Add progress reporting for named requirement resolution (#2605)	2024-03-22 04:01:10 +00:00
Charlie Marsh	d0789fc078	Preserve hashes for pinned packages (#2532) ... ## Summary When a user runs with `--output-file` and `--generate-hashes`, we should _only_ update the hashes if the pinned version itself changes. Closes https://github.com/astral-sh/uv/issues/1530.	2024-03-19 01:02:18 +00:00
konsti	060a2fb80b	Shrink `solve()` a little by moving formatting out (#2506) ... `solve()` is our main loop. Shrinking it down a little by moving formatting out makes it easier to follow.	2024-03-18 12:27:24 +00:00
Charlie Marsh	5a95f50619	Add support for PyTorch-style local version semantics (#2430) ... ## Summary This PR adds limited support for PEP 440-compatible local version testing. Our behavior is _not_ comprehensively in-line with the spec. However, it does fix by _far_ the biggest practical limitation, and resolves all the issues that've been raised on uv related to local versions without introducing much complexity into the resolver, so it feels like a good tradeoff for me. I'll summarize the change here, but for more context, see [Andrew's write-up](https://github.com/astral-sh/uv/issues/1855#issuecomment-1967024866) in the linked issue. Local version identifiers are really tricky because of asymmetry. `==1.2.3` should allow `1.2.3+foo`, but `==1.2.3+foo` should not allow `1.2.3`. It's very hard to map them to PubGrub, because PubGrub doesn't think of things in terms of individual specifiers (unlike the PEP 440 spec) -- it only thinks in terms of ranges. Right now, resolving PyTorch and friends fails, because... - The user provides requirements like `torch==2.0.0+cu118` and `torchvision==0.15.1+cu118`. - We then match those exact versions. - We then look at the requirements of `torchvision==0.15.1+cu118`, which includes `torch==2.0.0`. - Under PEP 440, this is fine, because `torch @ 2.0.0+cu118` should be compatible with `torch==2.0.0`. - In our model, though, it's not, because these are different versions. If we change our comparison logic in various places to allow this, we risk breaking some fundamental assumptions of PubGrub around version continuity. - Thus, we fail to resolve, because we can't accept both `torch @ 2.0.0` and `torch @ 2.0.0+cu118`. As compared to the solutions we explored in https://github.com/astral-sh/uv/issues/1855#issuecomment-1967024866, at a high level, this approach differs in that we lie about the _dependencies_ of packages that rely on our local-version-using package, rather than lying about the versions that exist, or the version we're returning, etc. In short: - When users specify local versions upfront, we keep track of them. So, above, we'd take note of `torch` and `torchvision`. - When we convert the dependencies of a package to PubGrub ranges, we check if the requirement matches `torch` or `torchvision`. If it's an`==`, we check if it matches (in the above example) for `torch==2.0.0`. If so, we _change_ the requirement to `torch==2.0.0+cu118`. (If it's `==` some other version, we return an incompatibility.) In other words, we selectively override the declared dependencies by making them _more specific_ if a compatible local version was specified upfront. The net effect here is that the motivating PyTorch resolutions all work. And, in general, transitive local versions work as expected. The thing that still _doesn't_ work is: imagine if there were _only_ local versions of `torch` available. Like, `torch @ 2.0.0` didn't exist, but `torch @ 2.0.0+cpu` did, and `torch @ 2.0.0+gpu` did, and so on. `pip install torch==2.0.0` would arbitrarily choose one one `2.0.0+cpu` or `2.0.0+gpu`, and that's correct as per PEP 440 (local version segments should be completely ignored on `torch==2.0.0`). However, uv would fail to identify a compatible version. I'd _probably_ prefer to fix this, although candidly I think our behavior is _ok_ in practice, and it's never been reported as an issue. Closes https://github.com/astral-sh/uv/issues/1855. Closes https://github.com/astral-sh/uv/issues/2080. Closes https://github.com/astral-sh/uv/issues/2328.	2024-03-16 10:24:50 -04:00
Charlie Marsh	d29645ce75	Error when direct URL requirements don't match `Requires-Python` (#2196) ... ## Summary Closes https://github.com/astral-sh/uv/issues/2195. ## Test Plan `cargo test`	2024-03-14 02:37:01 +00:00
Charlie Marsh	3799862f5d	Trim injected `python_version` marker to (major, minor) (#2395) ... ## Summary Per [PEP 508](https://peps.python.org/pep-0508/), `python_version` is just major and minor:  Right now, we're using the provided version directly, so if it's, e.g., `-p 3.11.8`, we'll inject the wrong marker. This was causing `pandas` to omit `numpy` when `-p 3.11.8` was provided, since its markers look like: ``` Requires-Dist: numpy<2,>=1.22.4; python_version < "3.11" Requires-Dist: numpy<2,>=1.23.2; python_version == "3.11" Requires-Dist: numpy<2,>=1.26.0; python_version >= "3.12" ``` Closes https://github.com/astral-sh/uv/issues/2392.	2024-03-13 00:11:50 +00:00
Charlie Marsh	79ac3a2a7e	Wait for request stream to flush before returning resolution (#2374) ... ## Summary This is a more robust fix for https://github.com/astral-sh/uv/issues/2300. The basic issue is: - When we resolve, we attempt to pre-fetch the distribution metadata for candidate packages. - It's possible that the resolution completes _without_ those pre-fetch responses. (In the linked issue, this was mainly because we were running with `--no-deps`, but the pre-fetch was causing us to attempt to build a package to get its dependencies. The resolution would then finish before the build completed.) - In that case, the `Index` will be marked as "waiting" for that response -- but it'll never come through. - If there's a subsequent call to the `Index`, to see if we should fetch or are waiting for that response, we'll end up waiting for it forever, since it _looks_ like it's in-flight (but isn't). (In the linked issue, we had to build the source distribution for the install phase of `pip install`, but `setuptools` was in this bad state from the _resolve_ phase.) This PR modifies the resolver to ensure that we flush the stream of requests before returning. Specifically, we now `join` rather than `select` between the resolution and request-handling futures. This _could_ be wasteful, since we don't _need_ those requests, but it at least ensures that every `.wait` is followed by ` .done`. In practice, I expect this not to have any significant effect on performance, since we end up using the pre-fetched distributions almost every time. ## Test Plan I ran through the test plan from https://github.com/astral-sh/uv/pull/2373, but ran the build 10 times and ensured it never crashed. (I reverted https://github.com/astral-sh/uv/pull/2373, since that _also_ fixes the issue in the proximate case, by never fetching `setuptools` during the resolve phase.) I also added logging to verify that requests are being handled _after_ the resolution completes, as expected. I also introduced an arbitrary error in `fetch` to ensure that the error was immediately propagated.	2024-03-12 10:13:57 -04:00
Charlie Marsh	1d21e65fbc	Skip prefetching when `--no-deps` is specified (#2373) ... ## Summary When running under `--no-deps`, we don't need to pre-fetch, because pre-fetching fetches the _distribution_ metadata. But with `--no-deps`, we only need the package metadata for the top-level requirements. We never need distribution metadata. Incidentally, this will fix https://github.com/astral-sh/uv/issues/2300. ## Test Plan - `cargo test` - `./target/debug/uv pip install --verbose --no-cache-dir --no-deps --reinstall ddtrace==2.6.2 debugpy==1.8.1 ecdsa==0.18.0 editorconfig==0.12.4 --verbose` in a Python 3.10 Docker contain repeatedly.	2024-03-12 03:44:02 +00:00
konsti	f70ae72874	Add a `-vv` log level and make `-v` more readable (#2301) ... Behind error messages, the debug log is the second most important resource to finding out what and why went wrong when there was a problem with uv. It is important to see which paths it has found and how the decisions in the resolver were made. I'm trying to improve the experience interacting with the debug log. The hierarchical layer is verbose and hard to follow, so it's moved to the `-vv` extra verbose setting, while `-v` works like `RUST_LOG=uv=debug`. For installing jupyter with a warm cache: * Default: https://gist.github.com/konstin/4de6e466127311c5a5fc2f99c56a8e11 * `-v`: https://gist.github.com/konstin/e7bafe0ec7d07e47ba98a3865ae2ef3e * `-vv`: https://gist.github.com/konstin/3ee1aaff37f91cceb6275dd5525f180e Ideally, we would have `-v`, `-vv` and `-vvv`, but we're lacking the the `info!` layer for `-v`, so there's only two layers for now. The `tracing_subcriber` formatter always print the current span, so i replaced it with a custom formatter.  Best read commit-by-commit.	2024-03-11 08:58:31 +01:00
Zanie Blue	10c4effbd3	Refactor incompatiblity tracking for distributions (#1298) ... Extends the "compatibility" types introduced in #1293 to apply to source distributions as well as wheels. - We now track the most-relevant incompatible source distribution - Exclude newer, Python requirements, and yanked versions are all tracked as incompatibilities in the new model (this lets us remove `DistMetadata`!)	2024-03-08 11:02:31 -06:00
Charlie Marsh	2e9678e5d3	Add support for Metadata 2.2 (#2293) ... ## Summary PyPI now supports Metadata 2.2, which means distributions with Metadata 2.2-compliant metadata will start to appear. The upside is that if a source distribution includes a `PKG-INFO` file with (1) a metadata version of 2.2 or greater, and (2) no dynamic fields (at least, of the fields we rely on), we can read the metadata from the `PKG-INFO` file directly rather than running _any_ of the PEP 517 build hooks. Closes https://github.com/astral-sh/uv/issues/2009.	2024-03-08 16:02:32 +00:00
Charlie Marsh	8620b5a52f	Make direct dependency detection respect markers (#2207) ... ## Summary When determining "direct" dependencies, we need to ensure that we respect markers. In the linked issue, the user had an optional dependency like: ```toml [project.optional-dependencies] dev = [ "setuptools>=64", "setuptools_scm>=8" ] ``` By not respecting markers, we tried to resolve `setuptools` to the lowest-available version. However, since `setuptools>=64` _isn't_ enabled (since it's optional), we won't respect _that_ constraint. To be consistent, we need to omit optional dependencies just as we will at resolution time. Closes https://github.com/astral-sh/uv/issues/2203. ## Test Plan `cargo test`	2024-03-05 17:25:06 +00:00
danieleades	8d721830db	Clippy pedantic (#1963) ... Address a few pedantic lints lints are separated into separate commits so they can be reviewed individually. I've not added enforcement for any of these lints, but that could be added if desirable.	2024-02-25 14:04:05 -05:00
Bas Zalmstra	4e011b305f	fix: expose types to implement custom `ResolverProvider` (#1862) ... <!-- Thank you for contributing to uv! To help us out with reviewing, please consider the following: - Does this pull request include a summary of the change? (See below.) - Does this pull request include a descriptive title? - Does this pull request include references to any relevant issues? --> ## Summary To integrate `uv` into `pixi` I need to specify a custom `ResolverProvider` to be able to specify that some packages are already installed by conda and should not be touched. However, some of the types required to implement your own `ResolverProvider` were not accessible through the public API. This PR basically adds them. ## Test Plan I didnt add an explicit test for this.	2024-02-22 08:59:03 -06:00
Charlie Marsh	7eaed07f6c	Move conflicting dependencies into PubGrub (#1796) ... ## Summary This revives a PR from long ago (https://github.com/astral-sh/uv/pull/383 and https://github.com/zanieb/pubgrub/pull/24) that modifies how we deal with dependencies that are declared multiple times within a single package. To quote from the originating PR: > Uses an experimental pubgrub branch (#370) that allows us to handle multiple version ranges for a single dependency to the solver which results in better error messages because the derivation tree contains all of the relevant versions. Previously, the version ranges were merged (by us) in the resolver before handing them to pubgrub since only one range could be provided per package. Since we don't merge the versions anymore, we no longer give the solver an empty range for conflicting requirements; instead the solver comes to that conclusion from the provided versions. You can see the improved error message for direct dependencies in [this snapshot](https://github.com/astral-sh/puffin/pull/383/files#diff-a0437f2c20cde5e2f15199a3bf81a102b92580063268417847ec9c793a115bd0). The main issue with that PR was around its handling of URL dependencies, so this PR _also_ refactors how we handle those. Previously, we stored URL dependencies on `PubGrubPackage`, but they were omitted from the hash and equality implementations of `PubGrubPackage`. This led to some really careful codepaths wherein we had to ensure that we always visited URLs before non-URL packages, so that the URL-inclusive versions were included in any hashmaps, etc. I considered preserving this approach, but it would require us to rely on lots of internal details of PubGrub (since we'd now be relying on PubGrub to merge those packages in the "right" order). So, instead, we now _always_ set the URL on a given package, whenever that package was _given_ a URL upfront. I think this is easier to reason about: if the user provided a URL for `flask`, then we should just always add the URL for `flask`. If we see some other URL for `flask`, we error, like before. If we see some unknown URL for `flask`, we error, like before. Closes https://github.com/astral-sh/uv/issues/1522. Closes https://github.com/astral-sh/uv/issues/1821. Closes https://github.com/astral-sh/uv/issues/1615.	2024-02-21 21:27:58 -05:00
Charlie Marsh	c2b75b64d2	Wait for distribution metadata with `--no-deps` (#1812) ... ## Summary We still need to wait for the distribution metadata (for direct dependencies), even when resolving with `--no-deps`, since we rely on it to report diagnostics to the user. Closes https://github.com/astral-sh/uv/issues/1801.	2024-02-21 14:45:09 +00:00
Bas Zalmstra	6ea49ef7bf	fix: expose DefaultResolverProvider (#1764) ... ## Summary The `DefaultResolverProvider` struct was not public. This PR exposes it so we can build our own and use this as a fallback. ## Test Plan I did not explicitly test this trivial change.	2024-02-20 11:34:19 -05:00
Charlie Marsh	505b99d9b6	Support recursive extras for URL dependencies (#1729) ... Closes https://github.com/astral-sh/uv/issues/1680.	2024-02-19 21:56:21 -05:00
Charlie Marsh	5c4cecaa85	Allow URL requirements in editable installs (#1614) ... ## Summary If an editable package declares a direct URL requirement, we currently error since it's not considered an "allowed" requirement. We need to add those URLs to the allow-list. Closes https://github.com/astral-sh/uv/issues/1603.	2024-02-17 15:20:23 -05:00
Aarni Koskela	bc14ed1613	Fix typos & add pre-commit configuration (#1487) ... Co-authored-by: Zanie Blue <contact@zanie.dev>	2024-02-17 18:16:50 +01:00
Charlie Marsh	9e0336c28a	Remove URL encoding when determining file name (#1555) ... ## Summary Closes https://github.com/astral-sh/uv/issues/1553.	2024-02-16 19:15:24 -05:00
Charlie Marsh	6392961f44	Add support for extras in editable requirements (#1531) ... ## Summary If you're developing on a package like `attrs` locally, and it has a recursive extra like `attrs[dev]`, it turns out that we then try to find the `attrs` in `attrs[dev]` from the registry, rather than recognizing that it's part of the editable. This PR fixes the issue by making editables slightly more first-class throughout the resolver. Instead of mocking metadata, we explicitly check for extras in various places. Part of the problem here is that we treated editables as URL dependencies, but when we saw an _extra_ like `attrs[dev]`, we didn't map that back to the URL. So now, we treat them as registry dependencies, but with the appropriate guardrails throughout. Closes https://github.com/astral-sh/uv/issues/1447. ## Test Plan - Cloned `attrs`. - Ran `cargo run venv && cargo run pip install -e ".[dev]" -v`.	2024-02-16 18:48:35 -05:00
Charlie Marsh	f25781ff6c	Support recursive extras (#1435) ... ## Summary We had a guard in the resolve to avoid "self-dependencies" (as in `gps3==0.33.3`), but this guard was _unintentionally_ filtering out recursive extras. Closes https://github.com/astral-sh/uv/issues/1342. ## Test Plan Taken from https://github.com/astral-sh/uv/pull/1352.	2024-02-16 11:42:04 -05:00
Zanie Blue	2586f655bb	Rename to `uv` (#1302) ... First, replace all usages in files in-place. I used my editor for this. If someone wants to add a one-liner that'd be fun. Then, update directory and file names: ``` # Run twice for nested directories find . -type d -print0 | xargs -0 rename s/puffin/uv/g find . -type d -print0 | xargs -0 rename s/puffin/uv/g # Update files find . -type f -print0 | xargs -0 rename s/puffin/uv/g ``` Then add all the files again ``` # Add all the files again git add crates git add python/uv # This one needs a force-add git add -f crates/uv-trampoline ```	2024-02-15 11:19:46 -06:00