Visual Studio Code
where does it ever end? Komodo -> Microsoft Visual Studio -> Atom -> Visual Studio Code
I am now learning Visual Studio Code
I am currently using VSC to edit Python to create Geoprocessing scripts that I can run in Docker containers.
Settings
Note that I revile the space in "Program Files" and the space in "ArcGIS Pro", so I install ArcGIS Pro at C:/ArcGISPro
Esri used to include a very old version of conda, as of 2.8 it's not so bad, but for other reasons I usually download Miniconda and install it.
If you do not use bash you probably don't need to read this part. Running "conda init --all" in bash threw errors at me. Editing the .bash_profile manually worked. Put something like this at the end of your .bash_profile
CONDA_PATH=/c/Users/bwilson/Miniconda3
export CONDARC=$HOME/bin/condarc
source ${CONDA_PATH}/etc/profile.d/conda.sh
I keep bin/condarc in a github repo at brian32768/windows_bin
You should be able to list available environments with
conda env list
and you should be able to activate the standard Esri environment with
conda activate arcgispro-py3
Your prompt will change to include [arcgispro-py3].
My condarc file now looks like this
There are many problems fixed here. Using condarc works from shells but I found I needed an environment variable CONDARC too so I set that in bashrc as described above.
# This was not working for me so I commented it out.
#channels:
# - esri
# - conda-forge
# - defaults
ssl_verify: true
envs_dirs:
- C:/ArcGISPro/bin/Python/envs
- ${LOCALAPPDATA}/ESRI/conda/envs
pkgs_dirs:
- ${LOCALAPPDATA}/ESRI/conda/pkgs
- C:/ArcGISPro/bin/Python/pkgs
changeps1: true
Confirm it's really reading the right condarc file with "conda info". Today mine looks like this,
active environment : None
shell level : 0
user config file : C:\Users\bwilson\.condarc
populated config files : C:\Users\bwilson\.condarc
J:\.condarc
conda version : 4.10.1
conda-build version : not installed
python version : 3.8.5.final.0
virtual packages : __cuda=10.1=0
__win=0=0
__archspec=1=x86_64
base environment : C:\Users\bwilson\Miniconda3 (writable)
conda av data dir : C:\Users\bwilson\Miniconda3\etc\conda
conda av metadata url : https://repo.anaconda.com/pkgs/main
channel URLs : https://repo.anaconda.com/pkgs/main/win-64
https://repo.anaconda.com/pkgs/main/noarch
https://repo.anaconda.com/pkgs/r/win-64
https://repo.anaconda.com/pkgs/r/noarch
https://repo.anaconda.com/pkgs/msys2/win-64
https://repo.anaconda.com/pkgs/msys2/noarch
package cache : C:\Users\bwilson\AppData\Local\ESRI\conda\pkgs
C:\ArcGISPro\bin\Python\pkgs
envs directories : C:\ArcGISPro\bin\Python\envs
C:\Users\bwilson\AppData\Local\ESRI\conda\envs
C:\Users\bwilson\Miniconda3\envs
C:\Users\bwilson\.conda\envs
C:\Users\bwilson\AppData\Local\conda\conda\envs
platform : win-64
user-agent : conda/4.10.1 requests/2.25.1 CPython/3.8.5 Windows/10 Windows/10.0.19041
administrator : False
netrc file : C:\Users\bwilson/.netrc
offline mode : False
Using clone inside ArcGIS Pro fails
Up until ArcGIS Pro 2.8, Esri installed the conda environment with root permissions so normal users could not modify it. The workaround was to clone and then use the clone as the base in future cloning operations. Cloning the environment instead of modifying the base environment is still highly recommended. I typically set up a new environment for each project as part of my workflow.
Autopep error
Install that autopep thing for syntax highlighting.
conda install autopep8
It's not finding Python!!
Here is a doc telling where it looks.
Put the commonly used variables into your user settings, File -> Preferences -> Settings -> User -> Extensions -> Python -> Conda Path
"C:/Program Files/ArcGIS/Pro/bin/Python/Scripts/conda.exe"
Reload VSCode. Intellisense should work for you now too.
Now when you select a Python version, the right ones should appear. Make sure you pick the right environment (for me I named it "arcgispro-py3-vscode")
If you do it this way you should be able to use conda correctly from a bash shell too.
(base) brian@murre:~$ conda env list # conda environments: # base * C:\Program Files\ArcGIS\Pro\bin\Python arcgispro-py3 C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3 arcgispro-py3-vscode C:\Users\brian\AppData\Local\ESRI\conda\envs\arcgispro-py3-vscode conda activate arcgispro-py3-vscode (arcgispro-py3-vscode) brian@murre:~$ python --version Python 3.6.10 :: Anaconda, Inc.
and so on...
ESRI .PYT files are not treated as Python
I put this in my global settings.json file (F1 File:Associations)
"files.associations": {"*.pyt": "python"}
The glory of debugging Python Flask apps
I use Conda for python environments, so I create a new env from the command line and then restrt VSCode/ Maybe I could create the env INSIDE VSCode but that's not how I do it. Once it's created and VSCode restarted
conda create -n flask conda activate flask conda install autopep8 conda install flask
To get going quickly I can just pick that version of python when I hit "F5" to run in the debugger. The service starts running on localhost, http://127.0.0.1:5000/ and you can connect via browser.
Console output shows you connections.
C:\Users\bwilson\source\repos\arcgis_rest> cmd /C "C:\Users\bwilson\AppData\Local\ESRI\conda\envs\flask\python.exe c:\Users\bwilson\.vscode\extensions\ms-python.python-2020.10.332292344\pythonFiles\lib\python\debugpy\launcher 57269 -- c:\Users\bwilson\source\repos\arcgis_rest\flask_test.py " * Serving Flask app "flask_test" (lazy loading) * Environment: production WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Debug mode: off * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit) 127.0.0.1 - - [05/Nov/2020 11:05:50] "GET / HTTP/1.1" 200 - 127.0.0.1 - - [05/Nov/2020 11:05:50] "GET /favicon.ico HTTP/1.1" 404 -
Setting breakpoints works. For example, set a breakpoint in a route handler then hit the associated URL and execution stops so you can examine variables, trace code flow, etc...
VSCode + Flask
Basically, VSCode is a totally awesome tool for developing Flask apps.
I can create a .vscode/launch.json
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Python: Flask",
"type": "python",
"request": "launch",
"module": "flask",
"cwd": "${workspaceFolder}/flask_auth_test",
"env": {
"FLASK_APP": "app.py", // a single py file here or a module name, typically "app"
"FLASK_ENV": "development",
"FLASK_DEBUG": "0"
},
"args": [
"run",
"--no-debugger",
"--no-reload"
],
"jinja": "true",
"console": "internalConsole" // I had to start using this to avoid "launcher timed out" failures in Windows 10.
}
]
}
The further glory of debugging ArcGIS Pro Python Toolboxes
There are notes here for Visual Studio and PyCharm. I based this section on that.
Defeat caching
First off you need to force reloading in ArcGIS Pro else you will have to quit and restart Pro every time you make a change in the Python.
In the PYT file do something like this
import importlib import your_tool_module import.reload(your_tool_module) from your_tool_module import YourTool
and when you are done developing, comment out the first three lines so that caching can work again. In Pro, use right-click + Refresh on the PYT to reload the python module(s).
Attach to a running Python
See Launch vs attach.
- Load up the tool in ArcGIS Pro (open it in other words.)
Remote development
I've now tried this tutorial and learned it works. Python in a Container I got a simple Flask app running and then switched to running even simpler Python scripts in the container.
When I needed to add volume support I discovered this page: VS Code Remote Development It explains the Remote Development extension pack.
- I can use Remote - SSH to treat a remote machine (say, Bellman) as the host for a remote project. (* As recommended by John Sullivan.)
- I can use Remote - Containers to treat a Docker container as the host.
- I can use Remote - WSL too but I don't use Windows Subsystem for Linux currently.
Remote SSH
This works splendidly but when setting up a new remote machine, you have to manually install the Python extension.
You will get an error whenever you run debug (F5) and not be able to select a python interpreter until you do.
Once it's set up, working remotely is exactly like working locally. Everything works. It's quite amazing.
Docker containers
I can keep the code on the local file system or in the container.
My first tests I used the Dockerfile to load my code into the image. It worked fine.
More options:
- clone from github into a running container
- keep code in a volume mounted on the container
Using a volume seems to make the most sense to me. In that setting I can still easily use command line git.
There is a sample based on python, it starts a Debian container and puts a Bash prompt into a Terminal window. It connects when you do F5. Your code is accessible on the local filesystem and in the mounted volume in the container.
git clone https://github.com/Microsoft/vscode-remote-try-python
