Commit Graph

7 Commits

Author SHA1 Message Date
Charlie Marsh
9e41f73e41 Respect non-sysconfig-based system Pythons (#2193)
## Summary

`pip` uses `sysconfig` for Python 3.10 and later by default; however, it
falls back to `distutils` for earlier Python versions, and distros can
actually tell `pip` to continue falling back to `distutils` via the
`_PIP_USE_SYSCONFIG` variable.

By _always_ using `sysconfig`, we're doing the wrong then when
installing into some system Pythons, e.g., on Debian prior to Python
3.10.

This PR modifies our logic to mirror `pip` exactly, which is what's been
recommended to me as the right thing to do.

Closes https://github.com/astral-sh/uv/issues/2113.

## Test Plan

Most notably, the new Debian tests pass here (which fail on main:
https://github.com/astral-sh/uv/pull/2144).

I also added Pyston as a second stress-test.
2024-03-05 21:23:35 +00:00
Charlie Marsh
60a78812f9 Extend system-install.yml to include virtualenv operations (#2190)
Just basic stuff like: we can create a virtualenv, we can install into
it (and not affect the system Python).
2024-03-05 01:46:00 +00:00
Charlie Marsh
7e1f361bb3 Add system install test for PyPy (#2189) 2024-03-04 19:44:18 -05:00
Charlie Marsh
a3c24e7bea Add system install test for choco (#2185)
Test installing Python via `choco`.
2024-03-04 19:37:07 -05:00
Charlie Marsh
70143b8626 Run Windows against Python 3.13 (#2171)
## Summary

In Python 3.13, at least in the current builds, there's no `python.exe`,
but there is `venvlauncher.exe`.

I've asked here about whether it's intended:
https://discuss.python.org/t/when-should-venv-scripts-nt-python-exe-be-present/47620.
But there's at least some evidence in CPython
[here](d457345bbc/Lib/venv/__init__.py (L270))
that we should fall back to these, and the tests pass.

Closes https://github.com/astral-sh/uv/issues/1636.
2024-03-04 21:49:17 +00:00
Charlie Marsh
b983ff4fa7 Prioritize PATH over py --list-paths in Windows selection (#2057)
`uv --system` is failing in GitHub Actions, because `py --list-paths`
returns all the pre-cached Pythons:

```
-V:3.12 *        C:\hostedtoolcache\windows\Python\3.12.2\x64\python.exe
-V:3.12-32       C:\hostedtoolcache\windows\Python\3.12.2\x86\python.exe
-V:3.11          C:\hostedtoolcache\windows\Python\3.11.8\x64\python.exe
-V:3.11-32       C:\hostedtoolcache\windows\Python\3.11.8\x86\python.exe
-V:3.10          C:\hostedtoolcache\windows\Python\3.10.11\x64\python.exe
-V:3.10-32       C:\hostedtoolcache\windows\Python\3.10.11\x86\python.exe
-V:3.9           C:\hostedtoolcache\windows\Python\3.9.13\x64\python.exe
-V:3.9-32        C:\hostedtoolcache\windows\Python\3.9.13\x86\python.exe
-V:3.8           C:\hostedtoolcache\windows\Python\3.8.10\x64\python.exe
-V:3.8-32        C:\hostedtoolcache\windows\Python\3.8.10\x86\python.exe
-V:3.7           C:\hostedtoolcache\windows\Python\3.7.9\x64\python.exe
-V:3.7-32        C:\hostedtoolcache\windows\Python\3.7.9\x86\python.exe
```

So, our default selector returns the first entry here. But none of these
are actually in `PATH` except the one that the user installed via
`actions/setup-python@v5` -- that's the point of the action, that it
puts the correct versions in `PATH`.

It seems to me like we should prioritize `PATH` over `py --list-paths`.
Is there a good reason not to do this?

Closes: https://github.com/astral-sh/uv/issues/2056
2024-02-29 15:06:29 +00:00
Charlie Marsh
9328b3c2ab Add a --system flag for opt-in non-virtualenv installs (#2046)
## Summary

This is essentially a wrapper around something like `--python $(which
python3)`, but gives users a portable and streamlined way to solve the
common pain point of using `uv` in GitHub Actions or a Docker container.

See: https://github.com/astral-sh/uv/issues/1526.
2024-02-28 19:48:32 +00:00