Where is what I'm editing?

[JerryDavis]

I'm trying to find a way to access the path of the notebook file (.ipynb) that I'm currently editing, in a way that would work either in ArcGIS Pro or in an external IDE like Jupyter or VS-code.  What I've done in the past, with ArcGIS Pro 2.8 (and possibly 2.9), is to use os.getcwd()to provide the folder that the current file being edited is in.  This works in an external IDE but doesn't work in ArcGIS Pro anymore.  

In Pro, something like the following will work, at least with the default workspace location, to provide the project folder: 

os.path.dirname(arcpy.env.workspace)

... and that os.path.dirname() method will of course also work if we know the path for the notebook file itself. However the same method will not work when editing the file with an external IDE like VS-code or Jupyter, since there's no knowledge of the default workspace for the project, and indeed there's no knowledge of the ArcGIS Pro project at all: our file is just sitting in a folder.

I purposefully standardize on editing these notebook files in the project folder (a slightly modified logic would work if I used a 'source' or 'notebooks' folder within the project folder just to keep things organized), to keep things simple for students; they can do things differently if they need to down the road as they get more comfortable. But currently, in ArcGIS Pro 3, os.getcwd() just returns 

'C:\\WINDOWS\\system32'

which is clearly not the project folder, and not where the .ipynb file I'm editing is located.  There are what would seem to be obvious advantages in being able to edit a notebook either in ArcGIS Pro or an external IDE, and go back and forth, but I haven't figured out how to do this in ArcGIS Pro 3.  

And here's a typical situation I want to work in both places, to set the workspace to a geodatabase "pen.gdb" in my project folder, thus providing code that is portable within the project folder, and an easy way to create other resources (e.g. geodatabases, folders) within that project folder.

import arcpy, os

projdir = os.getcwd()

arcpy.env.workspace = projdir + "\\pen.gdb"

It all boils down to a simple question:  Where is what I'm editing?

Environment:  [ArcGIS Pro 3.0.3, installed on my computer for all users, not just my user profile; Windows 10]

[KyleGonterwitz]

I am not sure if I am answering the question you are asking but if you want to use an external IDE with your ArcGIS pro cloned environment that environment python interpreter can be found at C:\Users\%USER%\AppData\Local\ESRI\conda\envs\arcgispro-py3-%clone name%

If you want to find the location where arcgis pro stores the internal jupyter notebooks created in arcgis pro I think by default those notebooks are found in the same directory as the pro project, which by default might be C:\users\%user%\documents\arcgis\projects

I think you would probably need to somewhat coordinate the location of the jupyter notebook with the interpreter environment to get the results you would expect working with an IDE outside pro, especially if you want to use the arcgis libs in that ide. 

[JerryDavis]

Thanks for the suggestion, but I don't think that fixes it.  I'm already standardizing on .ipynb files being stored in the project folder; I'm just needing my code to be able to use the path to that project folder, which should be the same as the folder my current .ipynb is stored in, as you note.  That I can usually get within ArcGIS Pro by using  os.path.dirname(env.workspace), but that doesn't work from an external IDE like Jupyter or VS-code, so I had found that os.getcwd() would work in either case. 

That works in Jupyter/VS-code and displays the folder the current file is in (which in my practice is the ArcGIS Pro project folder), but in ArcGIS Pro when editing the same file returns C:\\Windows\\system32, not where the .ipynb I'm currently editing resides. 

I'm trying to find code that will work in either environment when editing the same file.

[RhettZufelt]

This works if you are running code in separate IDE and reports the filename of the script running.  But, does not seem to work in a notebook, maybe it helps figure it out???

import inspect

configfile = (inspect.getfile(lambda:None))

print(configfile)

R_

[JerryDavis]

Interestingly, that returns C:\Users\myusername\AppData\Local\Temp\ipykernel_8588\4269868497.py which I suspect may be something created by the notebook environment for the code cell -- not sure how notebook cells get handled by the python interpreter.  Not the solution yet -- don't see how I'd get tot the .ipynb path from there -- but thanks for the suggestion.

[JerryDavis]

"Well, I have no idea how this happened, but somehow os.getcwd() is now returning the project folder in ArcGIS Pro 3, as before.  It's a Christmas miracle...."

I posted the above and accepted that as a solution.  However, the problem cropped up again.  What appears to be happening is that os.getcwd() not surprisingly simply gets the current working directory (thus the name cwd) in memory at the time.  If you start a new project, it'll have that project folder in memory, and that also seems to stick pretty well, except when it doesn't. Here's what it looks like when it works, for a project MyProject21 I created in the ArcGIS\\Projects folder:

However, I still sometimes get C:\\WINDOWS\\system32 as shown below (or another wrong folder, maybe from another project) and I haven't yet figured out quite when that happens, or how to fix it when it doesn't, in a repeatable way, so I can provide clear instructions to students.

[NickPappinWSU]

This is happening to me as well. Just know you aren't alone. Going to try and open a ticket with ESRI.

Nick

[NickPappinWSU · Accepted solution]

Hey Jerry,

I opened a ticket and while working with them found that if I open ArcGIS by double clicking on the project file vs opening up ArcGIS from the start menu and then opening the project it seems to open dependably in the project folder. I will try and post again with any new info.

Nick

[JerryDavis]

Thanks for checking on that, Nick, and thanks to Esri's support responder.  That solution makes sense, too, since by navigating to the folder in the os, you've set the current folder from its perspective.  I've tended to be inconsistent in how I open ArcGIS Pro.

Jerry