I know this thread is very old, but I thought I'd pass along some info related to it because I've just gone through a couple of days dealing with this too. I only just found the addition of a "g_ESRI_variable_1" variable to a script in a Project Package I had created because I was testing it to ensure what I had in mind would work. It didn't and I've spent two days trying to figure out why, but that's beside the point. I know now.
When I finally did stumble on this "g_ESRI_variable_1", I was reminded that I had run into the exact same problem about 10-15 years ago with ArcGIS Server 9.3 and again with 10.1. At both times, I was struggling with getting Geoprocessing Services to run properly after publishing. Eventually, looking into the v101 folder on the server, I discovered what ArcGIS Server was doing to the code during the publishing process each time. And each time, fixed the problems by "over-complicating" the things that the ArcGIS Server was changing erroneously. You'll get the idea in a moment. My point is that this is not a new problem only related to Pro. It's been in their source code for a while and they seem to feel it's a good thing to change code without informing the user. Otherwise, they would have done something about it by now.
What I've been struggling with over the last couple of days is that I have a project with scripts that I am putting in source control as a project package. The project's name is "my_project_name" and the first thing each script within it does when invoked is verify that it is running within the "my_project_name" project because that project is structurally set up as it needs to be for all of these scripts to work.
Unfortunately, ArcGIS Pro is finding this:
project_name = "my_project_name"
aprx = arcpy.mp.ArcGISProject("CURRENT")
pos = aprx.filePath.rfind(project_name)
if pos < 0:
arcpy.AddError("This script must be run within the '" + project_name + "' ArcGIS Pro project.")
sys.exit()
The project_name variable is used for many things within the scripts and ArcGIS Pro is changing them all to use g_ESRI_variable_1 because the project_name variable is instantiated with a string that is the same project name that the ppks file explodes to:
g_ESRI_variable_1 = os.path.join(arcpy.env.scriptWorkspace,'..\\commondata\\my_project_name1')
Once I realized that was the problem, and recognized it was the same problem I'd beaten my head against the wall over (repeatedly) many years ago, I intro'd the same fix I did then. I "hid" the string in question by complicating the code so ESRI stopped trying to "fix" it for me. So, now I have:
# project_name = "my_project_name" # doesn't work
project_name = "_".join(["my","project","name"])
Et voila.
Similarly, though not for this particular problem, but in previous ones, we got around some of the problems by providing our paths with "/" rather the "\" and using Python's os.path.normpath functionality to convert the code to Windows structure at run time. ArcGIS wouldn't change those or the ones when we built the paths using the os.path.join (or path.pathlib.join_path, now) but there had to be enough parameters passed that ArcGIS couldn't figure out the path. I'm guessing, then, that the reporter of this problem could probably try something like this (no testing, just off the top of my head) to break things up and confuse ArcGIS Pro enough that it wouldn't try to change the script:
# checkout_image_path= os.path.join(homefolder,"current_checkout_attachments")
checkout_image_path= os.path.normpath(homefolder) + r"\\current_checkout_attachments")
Anyway, just throwing this stuff out there in case someone else comes across this thread looking for ideas.
Good luck!!
jtm
