Does not start in terminal linux (without windows)

[ivanfdez]

The application does not start in linux terminal mode even with the --no-gui option, example a vps.

The idea is to run the app on a windows system to generate the token, then copy the config file to a linux terminal

I managed to get it working by removing the import pystray and the RetinaIcon class

As a suggestion, an option could be added to request a token in CLI as in the example:

https://github.com/google/gmail-oauth2-tools/tree/master/python

Using the url in a browser with generates an authorization code that is pasted to authorize and generate token

[Jamie-Landeg-Jones]

Similar use case here: I use an imap command line mail client with gmail, but gmail is disabling "traditional" authorisation, so I need to switch to oauth2. I realise I need to open a browser window to make the initial setup, but once that's done, my use cases are ALL on headless / no windows servers.

I'm also wanting code without any GUI dependency, so I'll try your suggestion above. Cheers.

[simonrob]

Thanks for reporting this. The --no-gui option definitely does work, so I'm assuming that the issue you're running into is that pystray expects a GUI backend to be present when it is imported, and it is the import itself that it causing a problem.

There are two options here, then:

• Modify the proxy to make the pystray import conditional on the --no-gui option (which you've successfully done, but I'm reluctant to do on the whole as it would require restructuring in quite a few places); or,
• Set an environment variable PYSTRAY_BACKEND with the value dummy, which allows pystray to load without any GUI toolkit being present.

Please could you try the environment variable option and let me know whether it works?

[ivanfdez]

With environment variable doesn't work.

Traceback (most recent call last):
File "/usr/local/lib/python3.7/dist-packages/pystray/init.py", line 41, in backend
candidates = [backends[backend_name]]
KeyError: 'dummy'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "emailproxy.py", line 34, in
import pystray
File "/usr/local/lib/python3.7/dist-packages/pystray/init.py", line 62, in
Icon = backend().Icon
File "/usr/local/lib/python3.7/dist-packages/pystray/init.py", line 43, in backend
raise ImportError('unknown backend: {}'.format(e))
ImportError: unknown backend: 'dummy'

dummy is not a valid option,
https://pystray.readthedocs.io/en/latest/usage.html#selecting-a-backend

In my case it works by removing the import pystray and the class RetinaIcon

I have been working separating the RetinaIcon class in a new file and importing it only if it runs in GUI mode

[simonrob]

Can you let me know which version of pystray you have? It looks like a change in how this environment variable is handled has broken the dummy backend.

I still think this would be a better approach than refactoring the proxy, however. So, if you force version 0.18.0 of pystray (pip install --upgrade pystray==0.18.0) and set the environment variable, does it work?

[ivanfdez]

with version 0.18.0 and export PYSTRAY_BACKEND=dummy it works.

In my case with 0.19.2 it didn't work for me

[simonrob]

Note: this workaround was correct at the time of writing, but is no-longer required now that the proxy has full support for headless operation via a separate non-GUI dependencies file.

Instead, install the script's requirements via python -m pip install -r requirements-no-gui.txt, and pass the --no-gui argument when starting the proxy.

---

Excellent - it looks like the dummy backend is the best way forward, and the second issue you encountered is a bug in pystray (which I'll report) that has now been fixed.

For the benefit of others, the solution to run the proxy with no GUI dependencies (and no need to edit the proxy script) is:

• Use pystray version 0.16.0 or later, but not 0.19.0 to 0.19.3
• Set an environment variable PYSTRAY_BACKEND with the value dummy
• Use the proxy's --no-gui option

Also – just to be clear: while this usage of the proxy will work, it has no way of requesting reauthorisation directly in this mode, so you will either need to monitor for log messages about authentication failures, or use the new --local-server-auth option, which provides a no-GUI way to handle authorisation requests.