Project packaging. Please stop messing up scripts with g_esri_variable_#

[RobertHooley]

more pain this morning with a project package adding g_esri_variable_# and breaking the script as discussed in this post below.

https://community.esri.com/t5/python-questions/script-are-changed-by-esri-with-g-esri-variable-1/m-p...

can this be stopped in the latest v3.x if not done so already?

Why add these variables? just package the code as is please

[KoryKramer]

Hi @RobertHooley sorry that you're running into issues. The community thread that you point to cites a bug that was fixed in ArcGIS Pro 2.6: https://support.esri.com/en/bugs/nimbus/QlVHLTAwMDExNjY1MA==

I found another potentially related bug here that indicates it was fixed in 2.5.1: [BUG-000115414: Including arcpy.env.workspace in a string in a Python argument in an embedded script...

Since it appears that the problem you're referring to is either a bug in a current release (TBD) or a bug that is already resolved, I am closing this as an idea. 

What version of ArcGIS Pro are you currently on? If it is a version later than 2.6, it sounds like this should be reported to Technical Support and investigated as a bug. Thank you.

[RobertHooley]

thanks for the response 

version is

2.8

why does it need to edit the code at all? 
wouldn’t a copy/paste operation when it embeds the toolkit just make life easier for everyone?

the packaging also likes to add phantom directories which you see when you unpack the project. These contain a single file called emptyPlaceHolder.txt .. there is no sensible reason for the packager to do this.

these phantom directories seem to relate to these g esri variables.

I have had to ditch packaging from our procedures and just get people to copy and paste toolkits and import map files because of these issues

will report as a bug when time allows

[DonMorrison1]

I'm on ArcGIS Pro 2.9 and also am now seeing problems with the consolidator messing up my code.  In my case it took a string "Organization" and replaced it with g_ESRI_variable_7 plus this

g_ESRI_variable_7 = 'Organization..\\..\\GitRepos\\ROW_as_habitat\\row\\pro_project\\ROW as Habitat\\shared\\Organization'

Now the toolbox that I published last night into our production environment is broken and I don't know how to fix it.  Is there any way to tell the consolidator to leave a string alone?  @KoryKramer  I really need to figure out a way to get around this ASAP.

BTW, I saw another case yesterday where a string was botched by the consolidator but republishing fixed it.

UPDATE 30 minutes later:   I republished and this latest problem went away.  However I have about 10 tools that I often publish so if this is some sort of random problem then it's going to be very costly to have to thoroughly test the tools after every publish just to make sure my strings didn't get corrupted.