-
Notifications
You must be signed in to change notification settings - Fork 762
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: allow passing extra config k,v pairs for pyvenv.cfg when creating a venv #1852
feat: allow passing extra config k,v pairs for pyvenv.cfg when creating a venv #1852
Conversation
47c8c42
to
03eaffd
Compare
835ba9c
to
1f95a17
Compare
Thanks! |
Shouldn’t |
I think the "API" should be uv with gourgeist being more an implementation detail. What's your use case for checking who created the venv? |
@henryiii Can you look for |
I can look for either one. I need to know if we need to regenerate the environment if a user changes the provider. This is especially important for uv vs. venv/virtualenv, since we are installing pip into those environments but not uv. |
Technically, since it didn't matter before (unless someone switched venv or virtualenv with conda or mamba, which would have been a mess but not something very common), the mechanism is weirdly opt-in via a secret environment variable, but I think I can fix that. |
Read the key read for uv from `pyenv.cfg` from `gourgeist` to `uv`. I missed that we're also reading pyenv.cfg when reviewing #1852.
Read the key read for uv from `pyenv.cfg` from `gourgeist` to `uv`. I missed that we're also reading pyenv.cfg when reviewing #1852.
Read the key read for uv from `pyenv.cfg` from `gourgeist` instead of `uv`. I missed that we're also reading pyenv.cfg when reviewing #1852. We could check for gourgeist for backwards compatibility, but i think it's fine this way.
## Summary This is mainly a cleanup PR to leverage uv-version in uv-virtualenv instead of passing it via `uv`. In #1852 I introduced the ability to pass extra cfg to `gourgeist` for the primary purpose of passing the uv version, but since the dawn of the uv-version crate dynamically passing more values to pyvenv.cfg is no longer needed. ## Test Plan Existing `uv` tests should still verify `uv = <version>` exists in the venv and make sure no regressions were introduced.
Summary
This modifies
gourgeist
to allow passing additional k,v pairs to add to thepyvenv.cfg
file as proposed in #1697.I made it allow an arbitrary set of pairs (to decouple from
uv
since this is mainly a change togourgeist
) , but I can slim it down to just allow just a name and version strings if that's desired.The
pyvenv.cfg
will also have auv = <uv-crate-version>
when a venv is created viauv venv
and.uv-build = <uv-build-crate-version>
when it's created viaSourceBuild::setup
Example below via
uv venv
:Open to any suggestions, thanks!
Closes #1697
Test Plan
Added new test in
tests/venv.rs
calledverify_pyvenv_cfg
to verify that it contains the right uv version string. I didn't see tests configured ingourgeist
itself, so I didn't add any there.