Python Library Location Will Not Stay Deleted

Somewhere along the line I must have added a few additional locations for Python within GH to search for libraries. After some more time, I noticed that none of my python blocks in any definitions were working. I traced the problem back to those additional library search locations in that if I delete the search paths from within a Python block within a given GH definition, all the Python blocks within that definition will begin working perfectly again. However, no matter how many times I try to save a block, restore those file locations to default, create a new Python block and save it with the default search locations, every time I open any Python block, those locations are still there. In addition to making all of my Python blocks fail, these locations also make no sense as they are nested, so I’d love to remove them. Any and all thoughts would be so welcome!

Those are 4 standard paths for a normal Python env or install. The Python running in that env may well try to recreate them, if it can’t find them. Deleting them breaks that Python, and it should be discarded, e.g. like normally deleting a venv.

But if the CPython in Rhino thinks those are its home directories now (instead of the normal ones in the Rhino Python directories), then the Rhino Python you’ve got installed is broken.

Either that or something’s added something elsewhere in the Rhino settings, or even in the registry, that has decided those paths are the CPython’s system paths. Unfortunately all Python apps in Grasshopper share certain resources, such as folders they import from. They can’t be isolated, e.g. using venvs like with stand alone Python run times. Even more unfortunately, not every piece of software is a good citizen of user land, that cleans up after itself. Some even take elaborate steps to make permanent changes to the Python system path, to suit themselves and noone else.

What’s that Trajectory app you have installed?

2 Likes

James, after reading your reply, I figured that while I couldn’t get this specific interface to just let go of those pathways, I might be able to get it to let go of those pathways if I showed it the correct Rhino Python directories at the same time. Miracles ensued. I deleted all the existing pathways and at the same time added the pathway to the McNeal folder in AppData which contained the correct libraries. Thankfully it then saved properly and all my GH definitions open and work properly now! You da man!

Great stuff. You’re most welcome Sean. Well done!