dd0825c...
by
Andrew Gallant <email address hidden>
scripts/scenarios: skip tests related to 'local' versions
These tests aren't passing yet, but we hope that at least some of them
will one day.
e0ded9b...
by
Andrew Gallant <email address hidden>
scripts/scenarios: update instructions for latest upstream changes
The packse workflow has been simplified somewhat. Particularly
now that building dumps scenarios into the same directory that
the index serves. So there's no need for a separate publish step.
995fba8...
by
Charlie Marsh <email address hidden>
Surface the `EXTERNALLY-MANAGED` message to users (#2032)
3116c37...
by
Charlie Marsh <email address hidden>
Add `uv pip install --python` to README (#2030)
1017514...
by
Charlie Marsh <email address hidden>
Add a `--python` flag to allow installation into arbitrary Python interpreters (#2000)
## Summary
This PR adds a `--python` flag that allows users to provide a specific
Python interpreter into which `uv` should install packages. This would
replace the `VIRTUAL_ENV=` workaround that folks have been using to
install into arbitrary, system environments, while _also_ actually being
correct for installing into non-virtual environments, where the bin and
site-packages paths can differ.
The approach taken here is to use `sysconfig.get_paths()` to get the
correct paths from the interpreter, and then use those for determining
the `bin` and `site-packages` directories, rather than constructing them
based on hard-coded expectations for each platform.
- Verified that, on my Windows machine, I was able to install `requests`
into a global environment with: `cargo run pip install requests --python
'C:\\Users\\crmarsh\\AppData\\Local\\Programs\\Python\\Python3.12\\python.exe`,
then `python` and `import requests`.
- Verified that, on macOS, I was able to install `requests` into a
global environment installed via Homebrew with: `cargo run pip install
requests --python $(which python3.8)`.
72a5eba...
by
Charlie Marsh <email address hidden>
Un-cache editable requirements with dynamic metadata (#2029)
In this context, we already know (as the comment says) that `self` does
not have a local segment, so we don't need to strip it.
This change isn't motivated by anything other than making the code and
comment in sync. For example, when I first looked at it, I wondered
whether the extra stripping was somehow necessary. But it isn't.
