Commit graph

6 commits

Author SHA1 Message Date
Zanie Blue
306a4d7ce3
Improve logging of interpreter implementation (#3791)
```
Found Python interpreter CPython 3.12.3 at...
```

instead of

```
Found Python interpreter cpython 3.12.3 at
```
2024-05-23 10:00:45 -05:00
Zanie Blue
d5ac2f53d3
Improve display of interpreter implementation names (#3749)
e.g. instead of

```
❯ uv venv --python pypy@3.10
  × No interpreter found for pypy 3.10 in search path
```

we say

```
❯ uv venv --python pypy@3.10
  × No interpreter found for PyPy 3.10 in search path
```
2024-05-22 18:22:09 +00:00
Zanie Blue
1379fb7dcd
Add support for requesting pypy interpreters by implementation name (#3706)
Updates our executable name searches to support implementation names
i.e. `cpython` and `pypy` and adds support for PyPy.

We might want to _not_ support searching for `cpython` because that's
non-standard?
2024-05-21 16:48:43 -05:00
Zanie Blue
19df1a4372
Rename all instances of Cpython to CPython (#3702) 2024-05-21 14:52:31 -05:00
Zanie Blue
d540d0f28b
Rewrite Python interpreter discovery (#3266)
Updates our Python interpreter discovery to conform to the rules
described in #2386, please see that issue for a full description of the
behavior. Briefly, we now will search for interpreters that satisfy a
requested version without stopping at the first Python executable.
Additionally, if retrieving information about an interpreter fails we
will continue to search for a working interpreter. We also add the
plumbing necessary to request Python implementations other than CPython,
though we do not add support for other implementations at this time.

A major internal goal of this work is to prepare for user-facing managed
toolchains i.e. fetching a requested version during `uv run`. These APIs
are not introduced, but there is some managed toolchain handling as
required for our test suite.

Some noteworthy implementation changes:

- The `uv_interpreter::find_python` module has been removed in favor of
a `uv_interpreter::discovery` module.
- There are new types to help structure interpreter requests and track
sources
- Executable discovery is implemented as a big lazy iterator and is a
central authority for source precedence
- `uv_interpreter::Error` variants were split into scoped types in each
module
- There's much more unit test coverage, but not for Windows yet

Remaining work:

- [x] Write new test cases
- [x] Determine correct behavior around executables in the current
directory
- _Future_: Combine `PythonVersion` and `VersionRequest`
- _Future_: Consider splitting `ManagedToolchain` into local and remote
variants
- _Future_: Add Windows unit test coverage
- _Future_: Explore behavior around implementation precedence (i.e.
CPython over PyPy)

Refactors split into:

- #3329 
- #3330 
- #3331
- #3332

Closes #2386
2024-05-21 14:37:23 -05:00
Zanie Blue
c28a2806b3
Separate interpreter selectors into implementation and platform modules (#3332)
Split out of #3266

The "selector" concept doesn't seem well enough defined as-is. For
example, `PythonVersion` belongs there but isn't present. Going for
smaller modules instead.
2024-05-02 11:55:01 +00:00