2023 Python Issue

[jabowabo]

Versions 2022 and up compile custom Python files in folder ...Custom Scripts/__pycache__ and also append '.cpython-37' to the file name. Catalog Builder throws an error for invalid path when .pyc files in this location are selected to create a new part. The only way I can get CB to accept a script file path is to move it to the same folder as the original .py file and rename the .pyc to remove '.cpython-37' from the filename. This seems like it may create issues.

Does anyone know the correct way to use scripts in Catalog Builder for the newer versions?

[matt.worland]

I tested in both 2023 and 2024 and it looks like they are working on this end.

I'm using the standard OOTB CustomScripts folder in all of my specs and catalogs. Checking my updates, it looks like Im missing the 2023.0.2 update from May, but other than that, Im running pretty much out of the box settings. Im not sure of any other differences, but happy to test if time permits.

[jabowabo]

Thanks Matt. We typically work off our server but I also tested with the default local path and still get the same error. We moved from v2018 to v2023 and I suspect the problem is related to script migration from Python 2 to 3 but I'm not sure. Trying to figure out how to do that now. Can you check your script accompanying .xml file to see if it looks much different than below?

[matt.worland]

Here are the contents of the XML I tested.

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfScript xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<Script Name="BL_CBTR_SS" LDesId="BL_CBTR_SS_L" SDesId="BL_CBTR_SS" ConnPortNum="2" LengthUnit="in" >
		<Params>
			<Param Name="S" LDesId="BL_CBTR_SS.S" SDesId="BL_CBTR_SS.S" Type="STRING" Ask4Dist="false" Value="24" pg="MainDimensions" />
			<Param Name="TY" LDesId="BL_CBTR_SS.TY" SDesId="BL_CBTR_SS.TY" Type="ENUM" Ask4Dist="false" Value="1" pg="MainDimensions" />
			<Param Name="W1" LDesId="BL_CBTR_SS.W1" SDesId="BL_CBTR_SS.W1" Type="LENGTH" Ask4Dist="false" Value="6.0" pg="MainDimensions" />
			<Param Name="L1" LDesId="BL_CBTR_SS.L1" SDesId="BL_CBTR_SS.L1" Type="LENGTH" Ask4Dist="false" Value="144.0" pg="MainDimensions" />
			<Param Name="RS" LDesId="BL_CBTR_SS.RS" SDesId="BL_CBTR_SS.RS" Type="LENGTH" Ask4Dist="false" Value="6.0" pg="MainDimensions" />
		</Params>
	</Script>
</ArrayOfScript>

This might be related, but a slightly different issue. One of our clients had a problem with the upgrade and running new Python scripts. We had to change their Shared content folder to the OOTB local setup, Run the PLANTREGISTERCUSTOMSCRIPTS, then change it back to their network location and copy all the files from the local folder to the network location. After that, they were able to run the Python scripts without issue.

When we migrated from Py2 to 3, we kept two sets of code for a while, then ran the Plantreg...  into each Plant version CustomScripts folder. Our code didn't have many changes when going from 2 to 3; some prints had to change, and other minor changes. We learned how aggressively the PlantReg... command finds files in the CustomScripts folder. We originally kept both Py versions in a single folder as a backed-up zip folder, and that caused some issues, so now it's all separated between Py2 and 3 and the respective plant version.

[jabowabo]

The issue does not appear to be related to Python versioning after all. I copied the scripts to the default local folder and re-registered them all. Still have the same issue - the only way I can get around the 'Invalid path' error is by moving the .pyc file to the same location as the .py file and removing the '.cpython-37' text string from the file name. Please see attached example video. Not sure what to try next, but appreciate any help.

[matt.worland]

The steps, in the beginning, are the same steps that I'm doing. It works here with no need to rename or move. I wonder if it's a false error message. Something else is triggering the error, but that is the only message showing?

[jabowabo]

---

@matt.worland wrote:
 Something else is triggering the error, but that is the only message showing?

---

I think you're right, but I haven't figured it out yet. I had an ampersand in the original path and the path was ~160 characters but those potential issues were ruled out when I moved them local. I vaguely remember having an issue with file paths in Catalog Builder a few years ago, but can't remember the solution and didn't save notes. I would use Spec Editor but these are supports and AFAIK, you can't create scripted supports in Spec Ed. Thanks for your help.

[李榕华|Ronghua.LI]

My method is to create a component library using spec editor and then export it to excel.

The operation steps can be referred to the following video.

https://www.bilibili.com/video/BV1544y1a7qA 

[jabowabo]

---

@李榕华|Ronghua.LI wrote:

My method is to create a component library using spec editor and then export it to excel.

The operation steps can be referred to the following video.

https://www.bilibili.com/video/BV1544y1a7qA 

---

As stated above, there is no group for Supports in Spec Editor.

---

---

[Michiel.Valcke]

I have little to no experience with custom python scripts, so if I apologize if my suggestion is completely out of left field. But it is possible to add supports directly from the supports catalog to a spec. You just have to look for *.acat files. (It's a little trick I picked up from @DVaquand's website)

Then you can add the supports as regular parts to your spec, afterwards you could export to excel and swap out the pythonscript name and parameters?

[jabowabo]

@Michiel.Valcke this might be a viable workaround, but our current workaround of moving and renaming the .pyc files is faster I think.

I did a complete uninstall/reinstall on a different PC and still have the same issue. Still not sure what's causing it. 

[matt.worland]

Not sure if you ever found a solution, but today, I have tried to put some scripts in a sub-directory. They compile and run just fine, but catalog builder throws the same error you are getting. For me it seems to only like files being in CustomScripts and __pycache__

[jabowabo]

---

@matt.worland wrote:

 For me it seems to only like files being in CustomScripts and __pycache__

---

We're just working around it the same way.