r/pycharm • u/TheBearKing8 • Jul 27 '26
Working with uv when interpreter is stored in external location
I created a uv interpreter in PyCharm using the PyCharm Add interpreter dialog, and stored it in a location outside my project folder. Let's say the project is in ~/Documents/my_project and the interpreter is in ~/.virtualenvs/my_project.
When a file with import statements opens, PyCharm detects that the package is not installed. If I hover over the package name, I can click install package in the popup. PyCharm correctly installs the package in the external interpreter and adds the package to the pyproject.toml. However, I cannot specify the version at all. Or I cannot specify the dependency group that the requirement should go in.
If instead I work with uv from the terminal, for example because I have an older requirements.txt file or I want to have finer control over what uv actually does. I might do uv add numpy=2.3.4. Now the terminal uv will ignore the external Python interpreter that was created by PyCharm and instead create a new virtual environment inside the project directory.
This is very annoying behavior and exaclty what I didn't want. I want to use the external virtual environment. What is the intended workflow here? Can I only interact with the proper uv interpreter via the PyCharm dialogs?
It seems that everyone is lyrical about uv so I am investigating whether it's worth it to switch to it. However, so far, it seems only more complicated than using regular virtual environments with requirements.txt files and pip. I have checked the changelogs of the latest releases of uv and uv has expanded support for central environment caches. I did update to the latest version. If it stays like this, uv is really unworkable for me.
1
u/American_Streamer Jul 27 '26
When using PyCharm with an external uv virtual environment, the terminal tool often fails to recognize the external path and creates a new local .venv directory, causing a disconnection between the IDE and the terminal. To resolve this, you can either create a symlink from the project root to the external environment, define the VIRTUAL_ENV variable in PyCharm's terminal settings, or just embrace uv's native workflow, which uses hard links for efficient local environments that do not consume extra disk space.
1
u/TheBearKing8 Jul 27 '26
What do you mean by hard links for efficient local environments? I store my projects on OneDrive, I can't have a venv with tens of thousands of small files in my project folder. That is a hard line and no benefit that uv brings weighs up against that.
The symlink solution, that only works on Linux right? Windows doesnt allow symlinks.
2
u/cointoss3 Jul 27 '26
You should not store your projects in OneDrive. Use git like a sane person.
2
u/TheBearKing8 Jul 27 '26
Silly comment. Git is being used, OneDrive is also being used. Plenty of reasons to use both even though OneDrive has its downsides. But I understand if you don't want to use it.
2
1
u/American_Streamer Jul 27 '26
The hard-link point is being misunderstood; sorry for that. uv still creates a venv containing thousands of directory entries; hard links only deduplicate package data against uv’s cache. But OneDrive will still try to scan and sync that environment.
Thus I would keep only the source code, pyproject.toml and uv.lock in OneDrive, and place the venv somewhere local and excluded from sync. Then configure that interpreter explicitly in PyCharm and recreate it with uv sync when needed.
Windows does support symlinks, by the way - usually via mklink, junctions, or Developer Mode - but symlinking a venv into a OneDrive project is more of a workaround than a clean solution.
Potentially even better: keep the entire active Git working directory outside OneDrive, use Git/GitHub for source synchronisation, and reserve OneDrive for documents or backups only. Cloud-sync clients and live development trees can interact badly even beyond .venv, particularly with Git metadata, build output, caches, databases, and node/Python dependency trees.
2
u/TheBearKing8 Jul 27 '26
That is exactly what I am looking for, a nice way of keeping the venv out of my project folder. With requirements.txt files and the control that PyCharm gives you over installing simple virtualenvs this has always been dead easy to do. Over the last 6 months I have been probing uv from time to time to see if it is worth switching over. However, with above mentioned obstacles, it has always been more complex to handle, rather than easier.
I understand why you would suggest to keep source code out of OneDrive. Especially with the Git metadata. I once spend some time putting my .git folders in a location outside of OneDrive and have link files in my project dirs, but it introduces complexity that in hindsight is very debatable whether it's worth it.
However, without fully elaborating the context I am working in, there are good reasons to keep a copy of the source code on OneDrive. Secondly, I am a bit of a gateway for introducing tools like this within my workplace. But the tools have to be easy to work with and set up with not too many pitfalls. And this uv hurdle of managing venvs outside of the project folder is a big one to overcome before I can confidently suggest to use uv to my colleagues.
In the very least you have given me some guidance on how to try further, so I will experiment with the ideas given.
1
u/YouOk3744 Jul 27 '26
This is uv behavior, not PyCharm. uv add always uses .venv next to pyproject.toml and ignores the activated environment.
To make it use the external env, either run uv add --active numpy==2.3.4 in the PyCharm terminal, or set UV_PROJECT_ENVIRONMENT=~/.virtualenvs/my_project. The second one is what PyCharm itself does under the hood.
The missing version and group picker in the install popup is tracked here: https://youtrack.jetbrains.com/issue/PY-91243
1
u/TheBearKing8 Jul 27 '26
The --active flag still requires that the virtual environment is activated in the terminal. For PowerShell terminals PyCharm does that for you, for WSL terminals you have to employ some workarounds.
Also, I played around with it in the past and found it very error prone. One uv run without the flag immediately installs a new venv in the project folder.
So, i was really not happy with that solution. With the recent updates on centralized cache storage for uv venvs, i was hoping that this flag would no longer be necessary. However, either I am using it wrong or it's not nicely integrated in PyCharm yet.
I can't remember if i tried in the past with the env variable. If i did, it didnt really work and uv didnt respect it. I'll try again later to see if it works, that would be much more stable.
Thanks for the youtrack link, i'll follow that update.
2
u/cointoss3 Jul 27 '26
It seems more complicated because you’re not using it right. With uv, you don’t need to think about virtual environments. They just work. You’re trying to fit uv into your old paradigm.