Displaying the broken path symbol (see screenshot). Right Click --> Check Syntax yields "No syntax errors". These were toolboxes that functioned fine from 2.9 thru 3.0.2, and then broke upon upgrading to 3.2. I continued to 3.3 and 3.4, but still broken. There are a couple toolboxes that did NOT break. I can't determine why they survived and the others didn't.
Thanks,
Zach
Are you able to cut one of these toolboxes down to a minimum reproduction of the error and then post it here?
Hi David. I think it's more efficient to include the entire .pyt as the they are 180 lines and 100 lines respectively. I can share a GitHub repo with an example of a functioning Python Toolbox and one that doesn't? For my part, I manually tried reconciling differences between the two and ruled out culprits. For instance:
This header:
# -*- coding: utf-8 -*-
# Version 1
def updateParameters(self, parameters):
return parameters
# Version 2
def updateParameters(self, parameters):
return
Happy to share the repo. I could drop 300 lines of python in a response if not.
thanks,
Zach
A Github repo is great, please post it when you can.
Possibly related to the updateParameters method since my two functioning examples (only one shared) have no code block or functionality in that method.
Thanks David
Alright, after swapping bits in and out of toolboxes, I managed to get something that looks virtually identical to your code working (attached). I can't even see what significant changes were made using a file diff tool, I have to assume there's some invalid whitespace characters in your source that I Ship of Theseus'd out of there. Let me know if this still gives you trouble.
Hi @DavidSolari thanks, it worked. However, I don't know how to apply this to my other .pyt files. It appears the issue involves line endings, specifically that my files have linux line endings - I think. I program in PyCharm on a Windows machine, so it could be a setting. I cannot determine how to simply replace /n with /r/n when converting line endings from Linux to Windows. Git Diff shows the difference between my files and your as simply the removal of ^M, which is a symbol for a carriage ending used in Windows.
1) What editor did you use to edit my files?
2) If you get a chance, can you simply open and resave? I wonder if it's that simple.
Something happened between Pro 3.0.2 and 3.1+ which may require tech support because I'm 6 hours into this troubleshooting.
Unfortunately I didn't run any bulk edit, in the process of cutting and pasting different chunks around I must have slowly erased all the bad line endings. I use Notepad++ for general text editing and you can use Edit → EOL Conversion to bulk convert a file. If you need to fix a mixed-ending file something like this should work:
import re
bad_file = r"C:\path\to\file"
good_file = r"C:\path\to\output"
with open(bad_file , "r") as f1, open(good_file, "w", newline="\r\n") as f2:
f2.write(re.sub(r"\r\n?|\n", "\n", f1.read()))
Thanks @DavidSolari . For clarity, the line endings were my suspicion, but not identified as the culprit - since I haven't solved this yet. I have tried: 1) matching your file visually (i.e. same number lines, etc.) 2) Involved in 1, I changed triple, single quotes to triple, double quotes in the method descriptions. 3) Tried changing line endings - unsure if executed properly 4) Ran your last code chunk successfully, but didn't fix problem.
You suppose this is eligible for tech support? The issue was caused by upgrading versions.
much appreciated,
Zach