Script runs fine in Terminal. But when invoked via service: No module named 'dropbox'

[porg]

1. I had initially installed pip3 install dropbox (the module) as your README.md instructed.
2. In the shell get_dropbox_link.py executes just fine.
   • In my setup placed in ~/bin/bin/ which is in my PATH.
   • All the dropbox API key + permissions work fine.
   • I get URLs for ~/Dropbox/* filepaths just fine.

3. But when pressing the shortcut, which invokes the service (aka Quick Action built with Automator), in this environment the dropbox python module seems to be no accessible, because I get this error:

   The action “Run Shell Script” encountered an error: “Traceback (most recent call last):
   File "/Users/•••/bin/bin/get_dropbox_link.py", line 37, in <module>
   import dropbox
   ModuleNotFoundError: No module named 'dropbox'

Remarks:

• I don't know Python at all, but I remember there is this important distinction whether to install a module only into a project or globally.
• And there is also pipx to ease some things with this, which I had installed (I think with brew AFAIR).
• But all this is fading memory to me meanwhile.
• I guess the bug lies in how the module got installed and is available in the python environment to other scripts.

[nk9]

It looks like there are two /bin directories in the error message. Can you check that the path is right in the Automator action?

[porg]

The filepath is correct, on my system I use:

~/bin/      # Base folder containing no binaries/scripts itself.
~/bin/my/   # My own scripts.
~/bin/dev/  # My scripts in development or yet unstable.
~/bin/bin/  # Foreign single binary or script file installations.

What about the missing dropbox python module?

[nk9]

Unfortunately, Python path issues are common and very hard to give precise advice about given the large variety of possibilities.

To debug, I would create an Automator script which prints the Python path and then also run the same in the terminal and look for differences. Then compare that to the location of the module on disk.

[porg]

Already at other occasions I noticed:

Automator's "Run shell script" environment ≠ My normal shell environment

• E.g. CLI apps installed via brew such as gsed(GNU sed instead of sed shipped with macOS) could not be invoked by just gsed but needed the full path /usr/local/bin/gsed.
• I suspect that Automator only initiates with the non-interactive shell instead of the interactive shell, which usually has all the user customizations (custom PATH, aliases, prompt customizations, etc)
• When I get the time, I will investigate this, and report back my findings.

[nk9]

I ran python3 -m site in Automator and got this result:

sys.path = [
    '/Users/nick',
    '/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python39.zip',
    '/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9',
    '/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/lib-dynload',
    '/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/site-packages',
]
USER_BASE: '/Users/nick/Library/Python/3.9' (doesn't exist)
USER_SITE: '/Users/nick/Library/Python/3.9/lib/python/site-packages' (doesn't exist)
ENABLE_USER_SITE: True

This is the same Python environment used by the system python3 binary at /usr/bin/python3, and it's different from my personal python3 environment (since I use asdf to manage Python versions).

So all that to say that the right solution is to install dropbox like this:

/usr/bin/python3 -m pip install dropbox

I've updated the script and README as well, so this should be resolved any future users too.

Thank you for pointing this out, and let me know if this has resolved your problem.

[porg]

Hi,

I installed your newest python script with the renewed instructions in README.md. (not with pipx like the first time)

It fails, but not early on, already later this time luckily. The dropbox package seems to be available to python this time.

The action “Run Shell Script” encountered an error: “Traceback (most recent call last):
File "/Users/me/bin/bin/get_dropbox_link.py", line 257, in <module>
main()
File "/Users/me/bin/bin/get_dropbox_link.py", line 77, in main
fetcher.fetch(args.paths)
File "/Users/me/bin/bin/get_dropbox_link.py", line 92, in fetch
with dropbox.Dropbox(
File "/Users/me/Library/Python/3.8/lib/python/site-packages/dropbox/dropbox_client.py", line 197, in __init__
raise BadInputException("app_key is required to refresh tokens")
dropbox.dropbox_client.BadInputException: app_key is required to refresh tokens”

On first glance this sounds to me as if it cannot get the API keys.

The previous version left them at: ~/.get_dropbox_link_conf.json with the content:

{
    "refresh_token": "XXX",
    "access_token": "YYY",
    "access_token_expiration": "2023-05-ZZZ"
}

Did the file location or JSON format change maybe?

• Can I fix this by renaming/editing the file?
• Do I need to repeat the whole API key registration procedure?

[porg]

I already got to the cause. No deep to reply for now. Will update here later.

[porg]

✅ I re-ran the entire procedure (including a new app key). Now works.

👉 In order that updating the script and/or resuming with earlier credential files gets more user friendly I created proposal:

• 8

[porg]

This issue is resolved from my side.

• But I wanted to leave closing to you, if there may be anything left.

[porg]

Thanks for this cool script!

• An integration/efficiency improvement that Dropbox themselves refused to make,
• Now made possible with a FLOSS script solution. Thanks!