Latest Contributions by ShaunWalbridge

@JTessier Got it. Custom environments can't be directly upgraded by the software upgrade process, because they weren't created by it (MSI files specify the files they have written, and those are the things they can change). To upgrade custom environments, follow the instructions provided here: https://pro.arcgis.com/en/pro-app/latest/arcpy/get-started/upgrade-an-environment.htm In most cases, it should be as simple as clicking the upgrade button within the UI, but it is possible to invoke from the command line or with a script as well. This process should migrate both custom installed conda and pip packages. ... View more

@JTessier the specific issue that @FakeName identified was fixed in Pro 3.3, which is if you had active things running against the environment that you're trying to upgrade it wouldn't correctly get upgraded and just leave you with the backup. It will now in that case fully restore the environment back to its original state, and the upgrade should work once those file handles are unlocked first. If you see specific issues with upgrading your custom environments, can you share details on what the failures are, and what kinds of packages are present in your environments? ... View more

Thank you for your submission. Unfortunately, it contains insufficient information for us to act on. If you are receiving a specific error code from the software, please provide details on your workflow and what tool is failing, and create a general post rather than an idea. Thanks! 感谢您的提交。遗憾的是，它包含的信息不足以让我们采取行动。如果您从软件收到特定的错误代码，请提供有关您的工作流程和哪个工具失败的详细信息，并创建一般帖子而不是想法。 谢谢！ ... View more

Thanks for your idea! Because Python takes non-trivial time to initialize itself and the modules loaded by ArcGIS Pro (which include NumPy, ArcPy and a number of other modules), it isn't in the interest of non-Python users to have it initialized at the application startup. Because Pro is used in many different ways, where possible we always want to remove dependencies from its startup because that time will have to be paid by all users regardless of use-case. What we do have in our existing issues is evaluating what we can do to reduce the time it takes to import the default set of Python libraries, or allowing delayed loading of some components which today happen all at once immediately on Python being loaded. If you know you want Python to load, you can have it happen automatically by keeping the Python window open in your Pro window layout, keeping the Geoprocessing pane expanded, or by using a project containing a Jupyter notebook, in those three cases Python will need to load alongside the application startup. Cheers, Shaun ... View more

Thanks for the idea! From what I understand you're trying to do, the existing alternative approaches would be to use envManager to operate multiple calls against a specific GDB: arcpy.env.workspace = "whatever.gdb" # find tables only in 'other.gdb': with arcpy.EnvManager("workspace": "other.gdb"):     for table in arcpy.ListTables():         print(table.name) # reset to the global state, now get 'whatever.gdb' results for table in arcpy.ListTables():     print(table.name) The other approach you could take if you have a large collection of geodatabases to search is to use arcpy.da.Walk instead. In that model, you'd point to some place higher up in your heirarchy that includes multiple geodatabases, then filter them as you go through the walk iterations:   import arcpy import os workspace = r"C:\data" feature_classes = {} # can change datatype as needed to filter separate groups walk = arcpy.da.Walk(workspace, datatype="FeatureClass") for dirpath, dirnames, filenames in walk: for filename in filenames: if dirnames: last_dirname = dirnames.split(os.sep)[-1] if last_dirname.endswith('.gdb'): if last_dirname not in feature_clases: feature_classes[last_dirname] = [] feature_classes[last_dirname].append(filename)   Given that there are a few well supported existing paths for this, I think it would be better to try and adopt those patterns rather than the functions changing their relationship with workspaces. ... View more

@CordulaGöke Thanks for your report. We upgraded to a modern supported version of libxml2, and it looks like the builds of libspatialite on both defaults and conda-forge do not support such a new libxml2. If you're OK working in a standalone environment, you can create one with `conda create -n libspatialite libspatialite` and it should work, but would be decoupled from the rest of Pro. Hopefully the other channels catch up on dependencies soon and have a release compatible with Pro, we potentially could package it but it is non-trivial given libspatialite's large number of dependencies. ... View more

@Marco_Foi Thanks for your report, I can confirm the issue. For now, you can work around this limitation by using the `sqlite3.exe` included within Pro's Python environment, the command will work there and `PRAGMA compile_options` will correctly show the rtree extension as available (and it is present within the sqlite3.dll). If you needed this from Python, you should be able to do a subprocess call to sqlite3, though of course that is inelegant. For the Python build, it looks like the build environment is picking up a slightly different version of sqlite3 that does not include these extensions. I'll add an issue for us to look at and address in future builds of Python we redistribute. In a separate standalone environment, you could also get the Python client their working with `conda create -n sqlite -c defaults python=3.11` which will have rtree drivers loaded, but wouldn't recommend mixing that with ArcPy and our custom Python environment. ... View more

What does `arc.check_product()` report when it runs? Are you having crashes with any data source? Does this work? d <- arc.select(arc.open(system.file("extdata", "ca_ozone_pts.shp", package="arcgisbinding"))) Edit: I tried on 3.2 with R 4.4 and was able at times to get crashes, I will look. For now I would try an earlier R version like 4.2 or 4.3. ... View more

I haven't closely checked, but I think this is due to changes in the caching system of Python 2 vs 3. Deleting the .pyc was a handy trick, but perhaps not a directly supported "feature" from the Python developers perspective, sometimes cached module loading introduces other downstream issues, and typically Python executions expect to only import something once.  There are tools like IPython's auto reload module which allows hot reloading (https://ipython.readthedocs.io/en/stable/config/extensions/autoreload.html) but using importlib is the best general practice currently because it is explicit. We've discussed having some kind of 'debug' mode that would try to reimport modules, but nothing in the software today for that. Cheers, Shaun  ... View more

I would try creating the environment from your normal user account rather than doing it as an administrator, if you do that you should see the environment in %LOCALAPPDATA%\ESRI\conda\envs by default. One thing you can try is just running the Pro notebook before installing anything into the initial clone to verify it works before making changes. There was an issue with clones that was fixed in 2.9 and 3.0 (see the Notebook FAQ) but that shouldn't apply for 3.1. ... View more

As @DanPatterson mentions, currently upgrading Pro is the right path. Libraries which use the Python C API are versioned against the release, and aren't cross-compatible with other releases of Python. That said, Python 3.7 or 3.9 are the releases available in all supported versions of Pro, so you're probably due for an update in any case. Python 3.7 was still receiving security fixes until last year, but Python 3.6 has been unsupported for a couple years now. ... View more

You should be able to access the control point information with the ArcPy CIM access, see the symbols CIM definitions for the item types. There are a few different elements in the CIM to support this behavior, I'd recommend you try experimenting with some data, then extract the CIM from the .aprx you're using to examine its structure. The ArcPy class works well, but a working mental model of the CIM layout is important to make effective use of it. Cheers, Shaun ... View more

I just did some light testing with Pro 3.2, and can confirm that saving the project will save the notebook without needing to separately save the notebook from the Notebook ribbon. Could you search your machine for .ipynb files and see if anything else turns up? From your description of it being missing in the project, perhaps the file was renamed or otherwise changed in a way that Pro didn't track, and the updated file is present elsewhere. The other thing that comes to mind is if for some reason the file is stored in a read-only location, the save button won't do anything, but that case is usually pretty obvious in the UI which has this at the top: I'm hoping the notebook is in a different location and you haven't lost work. If there is a persistent issue with notebook saving, obviously that's a bug and we can look at it. Cheers, Shaun ... View more

Can you try to run the propy.bat included with the Server installation and see if the issue reproduces there? The documentation at https://enterprise.arcgis.com/en/server/latest/develop/windows/scripting-service-publishing-with-arcpy.htm provides some additional information. You can also try running the Python 3 Command Prompt from the start group shortcut and start your Python session from that to confirm it works when activated through conda. Cheers, Shaun ... View more