search

astral-sh / rye

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

Export `VIRTUAL_ENV` when executing `python` inside a rye-managed project #1043

Closed ma-sadeghi closed 6 months ago

ma-sadeghi commented 6 months ago

Not sure if this was intentionally left out, but it'd be great if VIRTUAL_ENV was set when executing python inside a rye-managed project so third-party programs can still find the .venv path.

bluss commented 6 months ago

Do you have an example of a tool that is helped by this?

ma-sadeghi commented 6 months ago

Yes, pyjuliapkg is the standard tool for managing Julia dependencies from Python (mostly used as part of juliacall for creating Python-Julia interface). It relies on VIRTUAL_ENV to decide where to put the Julia dependencies:

https://github.com/JuliaPy/pyjuliapkg/blob/main/src/juliapkg/state.py#L61

bluss commented 6 months ago

Just as extra information for context, most python tools don't need this since if the currently running python is in a virtual environment that can be detected and the recommended way to detect does not use VIRTUAL_ENV, instead something along these lines https://stackoverflow.com/a/1883251

When a virtual environment has been activated, the VIRTUAL_ENV environment variable is set to the path of the environment. Since explicitly activating a virtual environment is not required to use it, VIRTUAL_ENV cannot be relied upon to determine whether a virtual environment is being used.

https://docs.python.org/3/library/venv.html#how-venvs-work

Again, this is just context for the feature

ma-sadeghi commented 6 months ago

Makes sense. I opened up a separate issue in the source repository to hopefully address it at root. Just to make sure I understood, would you still consider exporting VIRTUAL_ENV? or since it's not the proper way, you'd rather not? Thanks!

bluss commented 6 months ago

Maybe @mitsuhiko has better insight into what's best to do about that

mitsuhiko commented 6 months ago

We do set VIRTUAL_ENV for scripts, but not for Python itself. Reason being that python itself can discover the virtualenv with sys.prefix. I don't think it's correct for code to use anything other than that to discover virtualenvs.

ma-sadeghi commented 6 months ago

I agree, and so do the the devs/maintainers of the conflicting package (pyjuliapkg). (And are willing to accept a PR that fixes the way virtualenv is identified.) So, I'm closing this issue. Thanks for the follow up :)