search

astral-sh / rye

a Hassle-Free Python Experience
https://rye.astral.sh
MIT License
13.6k stars 466 forks source link

Add the ability to specify venv location from #1222

Closed nazq closed 2 months ago

nazq commented 2 months ago

Added a --venv option to many of the commands. If specified this will be the location of the venv to use for the given step. If not specified then the current .venv default is respected.

nazq commented 2 months ago

Added updates to the docs. Tried to keep the tone to the philosophy of single managed venv, with a small escape valve for CI tools.

nazq commented 2 months ago

@charliermarsh @mitsuhiko I'd love your opinion on this PR. Should cause no change in anyone's current rye flow but will allow more external tooling and parallelization. I have a few of these lined up once we can get this in. Lmk what you think. Thanks

nazq commented 2 months ago

@charliermarsh @mitsuhiko Reposting. I'd love your opinion on this PR. Should cause no change in anyone's current rye flow but will allow more external tooling and parallelization. I have a few of these lined up once we can get this in. Lmk what you think. Thanks

mitsuhiko commented 2 months ago

I already mentioned this before but I'm a strong -1 on this. We should find a way to eliminate all needs that require non co-located virtualenvs. Making this configurable will require a lot lot of complexity in tools that can no longer assume the layout of the project. I already wrote down my thoughts on this a few times. #371. There is also a more recent discussion on there: #1211

I'm going to close this for now.

nazq commented 2 months ago

Thanks for responding @mitsuhiko , much appreciated. I've currently moved some 90ish percent of all my projects over to rye and the experience is great. Rye + uv were the build tool change python (py/rust) has been waiting for.

Now before we dismiss this I think it's worth exploring it a little further. In general I don't even think about the venv any more when using rye but I do have some edgier cases which make the PR here appealing. One common case I have is mixed rust python builds or simply python builds which need to target multiple python versions. The single .venv makes it difficult to parallelise large build/test runs. I'm more than willing to add this functionality into other OSS tools which would then leverage rye and hopefully make it even more broadly used than today.

The PR here should have zero impact on anyone's day to day usage of rye, I was very careful to not change any the current functionality. But it then opens up wider opportunities, Rust brought speed to rye/uv. I think a change like this brings true exogenous parallelism.

There are alternatives to a --venv within rye I've played with, for example copying the project around into tmp folders, or even faking out the filesystem so rye still thinks it's using ./.venv but none seem as clean as adding this optional feature to the small number of commands which would need it.

I hope you reconsider, I think rye (and uv) have opened the universe of beaten down py developers to what could be. It would be great to expand on that without impacting any users.

Let me know your thoughts