Latest Contributions by ShaunWalbridge

Great, glad you found a solution that worked. The Python API team is aware of the traceback issue, unfortunately its caused by the uninstall of the old version (1.2.5) and they can't retroactively patch that, but will be able to insure it doesn't appear on future upgrades. ... View more

Thanks for the details. Yes, I can see how this inconsistency is annoying. I'm looking into this, and what the ideal behavior is for uses like this. Here are some alternative approaches you can use immediately: 1. Use an explicit path to your external toolbox for the import. This is brittle since it will be hard coded, but it should work fine for your immediate needs. 2. Copy your code into a module, and place that into the Pro site-packages directory (you can create a setuptools package or conda package for this as well). If you're making something more durable, this is a great way to start creating a library around the code you're using, and then you'll be able to import it elsewhere as well. 3. Add a .pth file which links to the directory where your external toolbox is. You can add this to the Pro site-packages, and it will add that location explicitly to the Python search path (for all processes). ... View more

OK, thanks. It isn't immediately clear to me why it is picking up the conda in your external Anaconda installation, since `where conda` lists the Pro provided one as a priority. But it clearly is, since all the information you posted from `conda info` is from the Anaconda environment, nothing matches what we ship. Could you try removing the Anaconda environment from your path? It is known to cause problems to have multiple Python environments on the PATH, here's what the Anaconda installation says: The other option is, if you don't really care which conda executable you're using, is to specify the full path to the environment you want to modify. So, do something like: activate "C:\Program Files\ArcGIS\bin\Python\envs\arcgispro-py3" conda upgrade -c esri --no-pin arcgis It looks like you have two environments called "arcgispro-py3" -- the one that ships with Pro, and a second one located in F:\Anaconda\envs. That likely is confusing this arrangement, since the message may be perfectly valid (if there is no arcgis package in that separate "arcgispro-py3" environment). Hope that helps, and happy to keep digging if this doesn't get you where you need to be. Cheers, Shaun ... View more

Phil, Could you open a command prompt, without having activated any conda environments, and paste the results of echo %PATH%? I suspect that your Anaconda installation is registered globally, and is masking the environment variables used by conda in the application. From the activated environment, could you also paste the output of set CON and where conda? Thanks! ... View more

 Curtis Price‌ Thanks for digging into this. I'm doing some research on my end, and will post here when that's done. For now, I recommend doing: import sys sys.path.insert(0, '') In the code block, as you mentioned in your second example. This is the exact behavior of a typical Python process, and will prepend the working directory of the current Pro project to the search path for Python code. There are valid reasons to block this behavior in an embedded use, but I'm checking if they apply to Pro specifically. Cheers, Shaun ... View more

Hello Nora Quesada‌, The current stable version of the bridge doesn't directly support dplyr, but you can try the pre-release for the next version, which does support dplyr. Could you try that version? It's available here:   Release v1.0.1.229 · R-ArcGIS/r-bridge · GitHub  To install it, you can either place the downloaded .zip file into the same directory as the r-bridge-install toolbox, or you can install it directly from R following this screencast. Thanks, Shaun ... View more

OK, thanks. Can you right click on the toolbox and select "Check Syntax", then copy the message that provides? ... View more

Hello Saffet, Could you elaborate on what isn't working? Is the installer not working, or you're unable to run the bridge once it's installed? Thanks, Shaun ... View more

If you install Pro 2.1, it ships with both Jupyter and the ArcGIS API for Python in its default environment -- everything should work out of the box. You can also create environments from the Python backstage (Project > Python), and install packages from that location, without needing the command line. The start menu group for Pro includes a shortcut for Jupyter which you can use directly, or you can invoke it by running "Python Command Prompt", then typing jupyter notebook. Let me know if that isn't clear, or you need any additional guidance. If you're using Pro, you shouldn't need to have a separate Conda install for the Python API at this time, and Pro 2.1 ships with Python 3.6, so you'll be in alignment on that front. Cheers, Shaun ... View more

Simon, Yes, you can use the same pattern to point at a layer file or direct connection when using arc.write to write the results out:   arc.write('c:/path/to/my.sde/dbname.layername', results.df) Where results.df is the data frame after you've made modifications. Cheers, Shaun ... View more

Hello Simon, To access data stored in an enterprise geodatabase, you have a couple of options: if it's just one layer you're working with, you can save a .lyr file, and work with that directly as a filepath. Otherwise, you can reference tables relative to their SDE connection file, see this answer for more details. Cheers, Shaun ... View more

Sara, Thank you for the reproducible example. It looks like lubridate converts its date objects into the Date class object, and the bridge isn't currently equipped to read these. For now, you can work around this by making this change on line 5 of your script: ID_PM25_2017$xDate <- as.POSIXct(mdy(ID_PM25_2017$xDate))‍ I've posted an issue on GitHub to track this, and will update you once we've resolved the underlying issue. Cheers, Shaun ... View more