App key separate from script file: Hassle free updates (=overwrites) and detection of credential file from earlier installs

[porg]

Precondition

You already had get_dropbox_link.py installed and had ran the initialization:

1. You created an app key on the Dropbox website and filled int into APP_KEY = in the script file get_dropbox_link.py
2. As a result the script (or the dropbox python module, I dunno exactly) created ~/.get_dropbox_link_conf.json

Problem

Now when you update a newer get_dropbox_link.py file over your old one, you have 2 problems:

1. You need to fill APP_KEY again in get_dropbox_link.py or it fails.
2. Also after you filled the APP_KEY again with a new generated app key, that fails, as the old ~/.get_dropbox_link_conf.json gets not overwritten by the new app key, but instead remains untouched and hence remains the old one and hence there's a mismatch/contradiction.

Proposed Improvements

1. The app key gets set not in get_dropbox_link.py but elsewhere, e.g.
   • a) sibling file get_dropbox_link_app_key.conf
   • b) passed only once during init via argument like --init-app-key="XXX" and then anyhow is not needed in variable APP_KEY but persisted in ~/.get_dropbox_link_conf.json (I'm speculating, not knowing)
2. If you had get_dropbox_link.py once on your system, but removed it, and later add it again, but you still have the credentials in get_dropbox_link_app_key.conf, it's clever enough and just uses them.

[porg]

I've also moved the APP_KEY and ACCOUNT_TYPE variables into the config file to simplify upgrading.

👍 Per se great! 👉 But it yet misses documentation. Please amend!

• The README.md does not mention the config file ~/.get_dropbox_link_conf.json at all.

• The following should be addressed there:

  • How the config file gets into existence?
  • Is it created by the script automatically on the first run? Must the user create it?
  • If auto-created, where must the credentials be filled? (I think this is currently outdated, still assumes writing into main script file).
  • What must be in the config file (mandatory)? What can be in the config file (optionally)?
  • Ideally you try out the process on an entirely fresh Mac user account (fresh copied script, no config file) possibly also with a Dropbox account which is fresh too or an existing one but with a freshly created App-Key (although for the same purpose), to describe the installation/upgrade procedure as complete and realistically as possible (= NOT on your parametrized environment). That way the documentation ensures to be up to date. And if you would be willing to set up a fresh "Try for free" Dropbox account, you possibly already could get the new style links returned then. Important: Don't forget to cancel within the 30 days before they charge!

• In particular please describe the "upgrade path" for users like me, whose ~/.get_dropbox_link_conf.json until before the recent Dropbox New Link API adaptations (after 2023-08-09) was like:

  {"refresh_token": "XXX", "access_token": "YYY", "access_token_expiration": "YYYY-MM-DDThh:mm:ss.nnnnnn"}

[porg]

Intermediary update:

• After updating the script file, invoking your hotkey, which invoked Automator, which invokes the script fails, as the script needs to re-configure its config file.

• Go to Terminal and invoke get_dropbox_link.py and it will guide you through it

$ get_dropbox_link.py ~/Dropbox/Public/some-file.png
=>Please provide your app's App Key. This is NOT an OAuth2 token.
Find the App Key in the App Console. See the README.
App Key: ••••••••••••••••••••••••

=> Which kind of Dropbox account is this App Key associated with?
[p]ersonal or [b]usiness? p
https://www.dropbox.com/s/xxxxxxxx/some-file.png?dl=0

After this ~/.get_dropbox_link_conf.json will have changed to this:

{"app_key": "XXX",
"refresh_token": "XXX",
"account_type": "PERSONAL",
"access_token": "XXX", // Note: Changed when script re-configured now.
"access_token_expiration": "YYYY-MM-DDThh:mm:ss.nnnnnn8" // Note: Changed to timestamp of re-configuration.
}