I just tested the old example file I developed and posted above to check if perhaps the API implementation broke or something. It still works on my system, so I assume the issue might be on the Google authorization side (i.e. the Credential output might be incorrect):
And here’s my dependency setup (i.e. the compiled .dll files from 2020 and their location, plus the client_secret.json file that you must provide yourself):
Thanks @AndersDeleuran. Meanwhile, I had resolved the issue. There was a conflict between the .dll from Bookworm and the ones pasted manually from the .zip.
Error: Runtime error (ImportException): No module named Sheets
and the same for Util.
Error: Runtime error (ImportException): No module named Util
In order to handle the problem, I have added the reference to the file Google.Apis.Sheets.v4.dll as well and apparently it has solved the issue with importing Sheet namespace. But in the original code only the reference to the Google.Apis.Auth.dll file exists.
Nevertheless, the problem with importing Google.Apis.Util.Store name space yet occurs, due to in the Dependencies folder no file to reference.
@AndersDeleuran, thank you for your speedy response, I really appreciate! But bizarre things happens with it for me. Do you think the issue can be on account of another OS (macOS)? I wonder why it can occurs at all, because the reference to Google.Apis.Auth.dll do works. I thought your script should work independetly of OS.
I really don’t know, but I would assume so. One way of testing would be to run the exact same setup (i.e. using your client_secret.json file and the dependencies/Grasshopper file I shared above) on a Windows/PC and see if that works. Perhaps someone that’s both a GHPython head and uses a Mac might help troubleshoot (e.g. @diff-arch).
Make sure that your defined paths are correct. An easy way would be to verify, if the following snippet prints two times True, if you paste it before you add the references to your environment:
I would also move the files and dependencies to your local drive into the Rhino scripts folder, instead of iCloud Drive. These cloud services often mess with stuff in the background, which is counterproductive.
On macOS, file permissions are strict! Rhino might or might not have permission to access (i.e. read, write, execute) files on your iCloud Drive?
Except the Windows file paths, which you have substituted for *nix ones with forward slashes, I don’t see anything that should not be cross-platform compliant in Anders’ code, judging from their screenshot above.
Anyway, I don’t use Google Docs, so there’s no way for me to test this.
@diff-arch thank you for your reply! I’ve tried your hypothesis and pull the entire folder to the scrips folder, but unfortunatly it doesn’t solve the error. Aloso I’ve checked the accessabily to the Google.Apis.Auth.dll, as you can see it’s fully readable, writable, executable and ofcourse exists).
I have no any thoughts what is going on. But anyway thank you again for your kind attempt to help me!
@AndersDeleuran I see you have Google.Apis.Auth2.Responses.TokenResponse-ander file, does the file matter? What is it?
It’s generated automatically when the script prompts a browser and have you provide your Google username and password that’s associated with the Sheets files you’re trying to fiddle with.
I think your file might not have the .json extension (i.e. it’s a file named client_secret.json with no type extension). You can turn on file extensions in your Explorer and check:
Just coming back to this as I need the Google Sheets import again. But I wonder if Google Sheets is even the right tool. It seems like Google really likes changing their APIs a lot and I still could never get around that weird caching issue, which only seems to happen here in in Switzerland. I know they build and test a lot of their services here. The Google Campus in Zurich is like 2 km from our office.
I might try and see if using the Swiftlet plugin makes it easier or even just switch to something like Airtable, which seems to have an easier to use API, while also allowing straight import from Google Sheets or any other CSV.
This Thread is a goldmine! not just for Grasshopper.
I referenced much of the knowledge shared by @AndersDeleuran to build a pyrevit extension since it runs on IronPython as well. So it works great universally for any application!
Exactly, that was my intention when developing this for the old BIG technical team. Back in between Flux.io dying and things like Speckle and Rhino.Inside existing. Glad it has been helpful to you
Is someone aware of any new progress regarding Google Apps access from Grasshopper? I am using Bookworm, but it’s completely written in C# some three years ago and I was not able to find a relevant knowledge base based on which to update it.
My project requires to run a custom apps script (in Google Sheet) to perform some operation on the data and return a JSON. This could be possibly done sending API GET request, but I was not able to find a solution how to protect data. The API cannot be accessible publicly and my knowledge of access tokens is very limited.
I think that once having a granted access to the Sheet, there should be a possibility to run a custom script using its deployment ID. There is some example in Python.
I’ve downloaded that for testing. Probably a wrong assignment of OAuth scopes (web API instead of desktop API) caused that the access was refused. I’ll try again. Anyway, since Google now has Python examples, would it be possible to rewrite the script from DLLs to python-only code? Or how could I see the content of dependencies and learn from that? My level of coding skills knowledge is rising but not enough still…
Thanks
Just to clarify a bit: the GHPython code I posted above implements the Google Sheets V4 API, which is still the current major version as far as I can tell. Back in 2018 I first implemented the CPython API in straight up Python outside of Rhino using Sublime Text, then the .NET API in C# using Visual Studio, and finally translated this C# code to IronPython and implemented the .NET API in GHPython (i.e. the implementation I’ve shared here). They seem to have removed the documentation/guides for this API, so maybe it is no longer officially supported. So if you’re already using Rhino 8, maybe the path of least resistance/future breakage is to implement the CPython API in the new script editor (i.e. that now ships with CPython 3). But as you can see, the GHPython code still works as well, so there’s also that
Ah that’s too bad, I can’t recall having seen that error. Let us know how you get on with implementing the CPython 3 API. Would be good to know if/how it works inside Rhino/Grasshopper
It’s actually pretty straightforward and I already tested it following the official tutorial. A few lines of code, fast response and probably a huge variety of implementations. No external dependencies required, except official Google’s libraries that are easy to install and include directly from Python3 component.
But there is some other bug that has to be adressed first - it has something to do with locale.py, but that is rather a common issue than Google-related. I follow this thread to get the answer.
