Visual Studio Code & ArcGIS Pro: A Way to Automatically Use the Current Environment?

[DavidSolari]

The year is 2026 and I still can't figure out how to get vscode to pick up on the current Pro python environment. I can select specific interpreters just fine but it's easy to get out of sync with Pro's environment, which can wreak havoc on testing.

Is there a proper solution to this? Prior answers seemed to work a bit but they involve adding the Conda scripts directory to the current PATH which goes against Conda guidelines. I figured out how to get a terminal profile added for Python work ...

"terminal.integrated.profiles.windows": {
    "Python": {
        "overrideName": true,
        "path": "C:\\Program Files\\ArcGIS\\Pro\\bin\\Python\\Scripts\\proenv.bat",
        "icon": "python"
    }
}

... but that doesn't handle the current interpreter. It looks like the Python extension adds a new environments view but it's clearly designed around venv and trying to view the packages in a conda environment just spits out a "Conda not found" error. How helpful.

If there isn't a full solution, little tips and tricks are still worth posting. Thanks!

[DanPatterson]

MarcoBorienga suggested

Esri/arcgispro-vscode-debugger

in this recent link

Hinduja Swiss (Switzerland) IT-Professional-How do... - Esri Community

I don't know if it works for your situation but is worth a look (ps Spyder has no problem in this regard and you can install it from spyder - esri | Anaconda.org )

[DavidSolari]

These are both great links! The vscode extension looks incredibly handy for debug work but it doesn't try to swap to the current environment, odd that it can read the current environment in the extension but can't offer a "click to sync" function. Spyder isn't really what I'm looking for for my type of work but that seems like a great IDE for more analytical work.

[HaydenWelch]

Are you trying to keep the environment in sync with your selected default in Pro? Or hook into the active Pro interpreter for a running session?

If it's the former, I usually just set the interpreter path as a workspace config and save different workspaces for each version of the conda environment I want to test. 

The latter is a bit harder to handle, I just tend to avoid using ESRIs confusing namespace hacking in favor of my own setups (unless I'm building a toolbox, but even then I don't write my tool code as a toolbox, I write my tool code as Python code and have a minimal tool wrapper that passes arguments).