Visual Studio Code: Difference between revisions
Brian Wilson (talk | contribs) mNo edit summary |
Brian Wilson (talk | contribs) |
||
Line 7: | Line 7: | ||
== Settings == | == Settings == | ||
Note that I revile the space in "Program Files" and the space in "ArcGIS Pro", so I install ArcGIS Pro at C:/ArcGISPro | |||
=== The Nightmare of Conda and ArcGIS Pro === | === The Nightmare of Conda and ArcGIS Pro === |
Revision as of 21:17, 9 June 2021
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
The Nightmare of Conda and ArcGIS Pro
You have ArcGIS Pro 2.5+ installed which installed the Conda environment for you which is great, but it's really old 4.4.x (or older).
Go to Anaconda.org and find Miniconda installer. Install it.
Put something like this at the end of your .bash_profile I tried doing "conda init --all" and it threw errors at me. Editing the .bash_profile manually is what worked.
CONDA_PATH=/c/Users/bwilson/Miniconda3 source ${CONDA_PATH}/etc/profile.d/conda.sh
Edit or create .condarc in your shell home directory. See below.
Note that your "base" environment when you are in a shell is not the one that Esri uses, so these commands will work fine for you.
conda install --name=root conda conda update -n base -c defaults conda
You can tell if it's working because the newer version lets you type
conda activate arcgispro-py3
...and your prompt will change to include [arcgispro-py3].
My .condarc file now looks like this
There are many problems fixed here including allowing a normal user to maintain environments and packages. Using .condarc works from shells but I found I needed an environment variable CONDARC="J:/.condarc" too
I tried using WINHOME in the path and sadly, it failed.
# 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 - C:/Users/bwilson/AppData/Local/ESRI/conda/envs pkgs_dirs: - C:/Users/bwilson/AppData/Local/ESRI/conda/pkgs - C:/ArcGISPro/bin/Python/pkgs changeps1: true
Confirm it's really reading your .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
It's a permissions problem, like most Windows developers, ESRI people do not understand permissions. I think the workaround was to clone outside of Pro and then use the clone as the base in future cloning operations in Pro.
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. } ] }
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.
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