nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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,

Encontre mais publicações marcadas com

Accepted answers

All comments

dougbrowning

When I talked to someone on the GP team they said if you save to a service definition file then you can see the changed script but I have not tested it yet.

ModyBuchbinder

I work a lot with gp services. This is very powerful tool but the doc's are not great and there are some bugs.

I could not do it without access the server directory and see the published script.

In most cases when you see the published script and you understand what the publish process do you can fix the original script and republished.

In some cases, updating the published script is the easiest way.

It is unsupported but I got this advise from esri support.

Dropping extra quote is something you can do on the published script.

If you do not have access to the server I would install local server just for these tests

Have fun

DonMorrison1

Unfortunately, I think any literal string can potentially be altered. Using the older python notation such as "hello %s goodbye" % (variable) works better the f string equivalent. It's a constant issue and I've had to go to some extremes to work around the problem - here is one example below where I create variables to represent the strings, then use those variables later on in the code. Of course to create the variable I have to trick the consolidator with the character replacement.

FQN =                   '?qn'.replace('?','f')                          # fqn
ORG_VIEW =              '?rg_view'.replace('?', 'o')                    # org_view
POLLINATORSCORECARD =   '?ollinatorScorecard'.replace('?', 'P')         # PollinatorScorecard
MANAGEMENTAREA =        '?anagementArea'.replace('?','M')               # ManagementArea
CENTERLINE =            '?enterline'.replace('?','C')                   # Centerline
SITE =                  '?ite'.replace('?','S')                         # Site
PROGRAM =               '?rogram'.replace('?','P')                      # Program
ORGANIZATION =          '?rganization'.replace('?','O')                 # Organization

GISDepartmentMFM

I'm not currently needing to hassle with any of this yet, but for future purposes what should you do in place of f strings? should you do "hello " + variable + " goodbye" for creating strings with variables in them?

DonMorrison1

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

Hayden Welch

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

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

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

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.

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

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

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.