Please, stop swizzling Python scripts

[Kepa]

Hi everybody,

I am struggling to understand how a script that runs flawlessly in ArcGIS Pro can be flagged as having syntax errors after the publishing process. This inconsistency is both frustrating and highly problematic, as it disrupts workflows and undermines confidence in the publishing system throughout our customers. I believe this situation requires immediate investigation and resolution to ensure a smoother and more reliable user experience.

Thanks,

[DougBrowning]

Yes it is a pain.  I have been battling it for weeks.  But you do have some things that can be fixed.  

Never use the \\ notation when publishing.  Always use os.path.join().  But it almost looks like this is from model builder?  It should not use that notation either.

I use arcpy.env.scratchFolder instead of the % notation - again not sure if model builder did that.

My scripts are getting 15-20 var remaps which then makes publishing take 20 minutes or more.  

In the end I gave up and use the old trick.  Comment out your entire script, publish, then go into the dir on the server and uncomment out the script.  This assumes you have server access which is really hard to get.  Then I still ran into issues with make raster layer and a few others like that work differently on server vs in Pro.  Even running the published tool in Pro or WAB also acts differently.  Just no consistency.

Hope that helps

[Kepa]

Hi Doug,

Yeah, it's a copy from a model but completely modified afterwards. Actually the % notation is the result after publishing, no matter what the staging/publishing process switches from arcpy.env.scratchFolder to %scratchFolder%.

Fortunately I have access to the server machine and I can fix it on the fly. But as you said, it's a constant pain. It's tough to get it done properly even with all the known tips & tricks .

IMHO, I rather get an error message when executing the tool because you missed something than this automated mess on the scripts... (deep sigh)

Thanks,

[DougBrowning]

Yea GP tools could be a huge homerun but the process is just so painful and buggy.  I have had tools that run great in Pro then some odd behavior when on server and I have to spend days tracking it down. I have seen Make Feature Layer and Make Raster Layer work totally differently.  I have been making posts to the Geoprocessing forum but never get a response.  

For sure stop trying to repath my scripts.  I even had it break SQL queries into many lines.  If the repathing worked then fine, but it does not work right so please give us a way to bypass it.  Plus 20 minutes or more to repath text in the script is confusing long.

In addition the server is not reporting the correct lines if it crashes.  It is giving a line from 20-50 lines up in the code which is super confusing to track down.

My other battle is the way selections work.  Its confusing in WAB and ExB does not respect selections at all.  Also toolbox categories that work in Pro do not in WAB.

[DonMorrison1]

I've been struggling with this for years and have spent an enormous amount of time working around this problem. I don't have access to the server where I could view the source code alterations, so that makes it even worse.  I don't know of any other situation where a component would alter my code in this fashion and I think is was a big mistake by ESRI to design it this way.  It is absolutely the most unproductive environment I've ever coded in (pushing 50 years) There must be a better way to provide portability between execution platforms.  A couple other tips

1. Avoid "f" strings
2. Avoid  non-trivial expressionsas parameters on arcpy calls 

[HaydenWelch]

Semi-related to this, but attribute rules on file geodatabases have their comments parsed when you save the rule, but not when you validate:

Meaning you can't just comment out code that doesn't work, you have to delete it.

Additionally, it will dig through string references to tables and replace them with a GUID if the table is deleted. Meaning that if you are re-building a featureclass and expect references to its name to survive you're out of luck and will have to manually go through all rules in other Featureclasses that used FeatureSetByName to reference it and replace the GUID with the table name again.

ESRI seems to have a habit of thinking they know better than their developers, and it's an absolute pain most of the time because the "Checks" they bake in are opaque and usually incorrect.

You can totally break python compatibility in pro by enabling this innocuous checkbox:

Which runs any loaded python scripts through the 2to3 module which is not only depreciated, but also always returns warnings if you have even a single valid print statement, so "Analyze" is so horrendously improperly named that I've seen people stump themselves as to why Python just doesn't work and throws a bunch of 2to3 errors on a system identical to another with this being the only difference.

[DonMorrison1]

"opaque and usually incorrect" - totally true. I can't think of a worse combination.