Export VIRTUAL_ENV when executing python inside a rye-managed project

[ma-sadeghi]

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]

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

[ma-sadeghi]

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]

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]

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]

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

[mitsuhiko]

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]

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 :)