New env handling

[wementoat]

Until now, the environment variables have been treated like common configuration files which should be replacable at runtime.

I do no longer think that that is a smart idea, as it leads to complexity and ambiguity, e.g.:
If you replace the API port, your client can't find it anymore, but you can't access the endpoint to replace the .env file to the old port anymore -> softlocked.

I have tried to refactor the handling with the following goals in mind:

• Create sensible defaults for all environment variables in the code -> those are checked at runtime
• Load a potential .env file from these sources to enable persistent configurations:
  • local root (development),
  • user_data_dir (application state)
  • bundle directory (packaged as .exe)

What do you think about this approach?

[sanssecours]

What do you think about this approach?

Sounds good to me. Less complexity/code is also nice in my opinion 👍.

I usually would recommend to use a configuration library, which can handle many of the problems that arise from having a configurable system. For example, dynaconf also supports .env files and provides additional goodies such as handling misconfiguration through validation. For now, I do not think it is necessary to switch, but I would also not be against it 🙂.

Anyway, the overall changes look good to me. I never looked into how to configure ICOapi myself though. As long as everything works with the default values, everything is fine for me.

Since you requested a review here are some general purpose recommendations:

1. “WIP” is probably not the best commit message 😅. For more information on how to write (even) better commit messages, please take a look at “How to Write a Git Commit Message”.

2. If you do not want to think about writing additional commit messages you can always rewrite the Git history, which is totally fine as long as you do it for a “feature branch”.

3. Regarding formatting: I would recommend we use black to auto-format code. At least that is what I use. While I agree that the formatting of the code

   backup_base[len(prefix) :]`

   does not look pretty (but seems to be intended behavior) I still think that just using a standard formatting tools helps immensely. Especially since it keeps the diff between commits (relatively clean) of formatting changes. My usual workflow for these formatting tools is to just use them automatically after saving (“format on save”). This is possible in most code editors or IDEs (such as PyCharm).

TLDR: Looks good to me 👍.