Provide ability to create new ArcGIS Pro projects from Python

[MaryGraceMcClellan]

I'm creating a script that will convert all of my MXDs to APRXs, and I find it extremely inconvenient that I can't create a new blank project from scratch form within ArcGIS Pro. This utility would make switching to ArcGIS Pro so much easier, along with the ability to create blank toolboxes. 

Edited to add: @Rhys-Donoghue posted a good workaround for this issue if anyone is interested. 

[Rhys-Donoghue]

@JeffBarrette and @MaryGraceMcClellan:

FYI, I have this working.  For one of my clients, I had to migrate hundreds of MXDs to ArcGIS Pro, and move their locations.  This is how I did it:

1. Create a blank aprx and save it to a temporary location, e.g. C:\temp\blank.aprx
2. For each MXD, import it into the aprx - e.g. aprx.importDocument(mxd)
3. Save the aprx to the new location - e.g. aprx.saveACopy(new_aprx)
4. Remap the datasources 
5. Check the datasources were mapped correctly and run a few other validation tests

It only took half an hour or so to write the script, and then took a bit longer to test and make changes to handle exceptions.  I didn't have any issues with the new aprxs.

@MaryGraceMcClellan if you still need help with this, let me know and I will see if I still have a copy of my script, or I can rewrite the script for you when I get a chance.

[MaryGraceMcClellan]

@Rhys-Donoghue  -- thank you for the follow up! I actually ended up doing something similar within my script if memory serves. 

[Rhys-Donoghue]

@MaryGraceMcClellan - awesome.  I have hundreds of useful scripts like these.  I will start putting them online when I get a chance.

[FredSpataro]

@Rhys-Donoghue I came up with about the same process... however one thing i'm noticing is that the 'projects home folder' is still mapped to the original 'folder of the blank aprx'.  Did you figure out a way to remap this? 

[JeffBarrette]

@FredSpataro there is an ArcGISProject.homeFolder property.  In fact when trying to rebuild a project using the techniques above by importing into a blank project, there are many other items to consider.

ArcGISProject.databases / updateDatabases

ArcGISProject.defaultGeodatabase

ArcGISProject.defaultToolbox

ArcGISProject.folderConnections / updateFolderConnections

ArcGISProjec.homeFolder

ArcGISProject.styles / updateStyles (Pro 3.3)

ArcGISProject.toolboxes / updateToolboxes (Pro 3.3)

ArcGISProject.updateConnectionProperties

We are considering creating New Project but there are some technical hurdles we need to resolve.

Jeff - arcpy.mp team

[JeffBarrette]

This is functionality we would like to provide in the arcpy.mp API but need to overcome a few technical hurdles.

[FredSpataro]

@JeffBarrette Thanks! Obviously this is not a normal type thing but now that i'm working thru it, I can see a lot of potential uses.  Couple other thoughts:

* It would be nice to have a similar method to ConvertLayoutFileToLayout for just the MAPX file.  Seems like this function already does the work since it imports the Layout and Map... why can't I do the same with just the map?  This technique is really useful for server-side geoprocessing services and the pagx/mapx files are easy to handle and keep in source control 

* I'm using 3.1.x right now (due to 11.1 at the Portal/Server level) and the .database and .updateDatabases isn't available until 3.2 ... took me a bit to figure out why i kept getting an error on thsoe.

* I was able to update the homeFolder, default toolbox, default geodatabase using the specific properties you mentioned. However it leaves references to the original atbx and gdb in the project.  Not a huge deal, someone can clean those open when they first open the project manually or otherwise not a big deal.  The database one probably cleans up when you use the updateDatabases() method but I'm not seeing anything that allow you to remove the toolbox.  removeItem() or a updateToolboxes method is probably needed as well? 

[rhys-kdrm]

@FredSpataro as @JeffBarrette mentioned above, this is how I would do it.

[MErikReedAugusta]

Stumbled upon this Idea today while trying to figure out how to initiate an APRX from Python, and was disappointed to see it's not currently possible.  I was also especially disappointed to see that almost all of the focus was based on the need to convert MXD to APRX, because of the approaching final sunset point of ArcMap and the decreasing utility of such a function.

Given that, I thought it might be helpful to provide two parallel use cases for the benefit of @JeffBarrette and the ESRI team that would still stand completely irrespective of ArcMap's status (since our team is fully on ArcPro, already) and help give reason for this functionality to come to arcpy.mp or the CIM or something similar:

Use Case 1:

Our team periodically receives requests for maps of sections of our stormwater system.  These are nearly the exact same map every time, with only the extents changing, so I built an APTX for us all to use for consistency & speed.  Our current workflow:

1. Open the Excel sheet where we track our projects, generate unique Project IDs, and determine the correct server location to save the project file(s).
2. Create a work order in our work order tracking system for the public record
3. Create a new Pro project based on the team APTX, based on the Project ID & server location from Step 1.
4. Navigate to the requested Area of Interest and set the requisite definition query(-ies) in our Parcel and/or Road datasets to match the request.
5. Output the final PDF and send it to the client
6. Update the work order from Step 2 & close out the job.

The two big problems we have with this workflow are Steps 1, 3, & 4.  First, that AOI data never makes it anywhere outside that project, so it's difficult to do things like analyze hot spots of map requests.  Second, the Excel project sheet has gotten quite unwieldy and was never supposed to be the de facto database that it's become, so I thought I'd combine Steps 1, 3, & 4 into a single step inside ArcGIS Pro by creating a "Master Project Database" APRX.

The thought was that we'd pop open that master project, designate the AOI, and then trigger a script that would go create a second APRX we're actually going to be working in to produce the map.  That way, all of our map requests and other projects are now in a central, spatially-aware and queryable database.  Sadly, this is apparently not possible with the current arcpy.mp library, based on this thread.  In theory, we could still do the master APRX, but all the steps creating the secondary APRX would have to be manual operations and prone to quite a bit of confusion and error among some of our team.

Use Case 1b/2:

The next use case is partially an extension of the above and partially a separate use case.  That same Excel database that tracks our map requests also tracks our internal team projects.  They're divvied up in a sufficiently similar way to the map requests that they work best in the same database, but they also have a number of minor differences, which added to the complexity of the Excel database.  The workflow is basically the same as above, but without the work order tracking system, and with a wider variety of APTX file setups we might be referencing as the baselines of our analysis work, based on project needs.

While the process is largely similar, the need is in many ways greater, because of the value in adding a spatial component to our project database.  But having to do a manual process involving multiple APRX files is not currently feasible or reasonable the way a partially-automated process could have been.

Based on my understanding of the "workaround" mentioned in here, it likely wouldn't work for either of these use cases, because avoiding "straggler" linkages in things like the Styles & Toolboxes would potentially be a tedious problem.  We're already dealing with that with an empty nonsense GDB that's stored itself in the APTX, as discussed in this other Ideas post.

[rhys-kdrm]

@MErikReedAugusta - you can easily update the .atbx and .gdb paths, e.g. 

aprx = mp.ArcGISProject("...")

aprx.homeFolder = "..."

aprx.defaultGeodatabase = "..."

aprx.defaultToolbox = "..."

# ...

aprx.saveACopy("...")

del aprx

I have run several migrations, and have had no issues with bad values being left behind.  I have also run several migrations that convert a feature service to an APRX file with all of the data copied, the symbology updated, and the data sources remapped.  This is all done with Python and is very fast.  You should be able to follow automate everything with no manual input needed at any step.  Let me know if you get stuck.