It seems that running the setzer executable with /usr/bin/env python3 as shebang will alter the process name to be python3. On the other hand, using full path to the python interpreter will force script name (setzer) as process name. As a bonus, application icon will also appear in System Monitor.
This is also what the PyGTK app GNOME Secrets did in order to get appname shown in System Monitor. The devs used full path to Python interpreter in the executable's shebang.
A consequence of this is that, since we're moving away from env, the interpreter path is determined only at build time. In theory, if this path is changed post-installation then the program must be rebuilt. I tested on my machine and the meson command that returns the interpreter path, import('python').find_installation().full_path(), returned /usr/bin/python3, which should default to any python 3 interpreter. So in reality this is stable enough, so I think this should be no problem.
Solve #371
It seems that running the setzer executable with
/usr/bin/env python3
as shebang will alter the process name to be python3. On the other hand, using full path to the python interpreter will force script name (setzer) as process name. As a bonus, application icon will also appear in System Monitor.Before:
After:
I'm not sure if there's an explanation for env's behavior. Taken from this Stack Overflow answer.
This is also what the PyGTK app GNOME Secrets did in order to get appname shown in System Monitor. The devs used full path to Python interpreter in the executable's shebang.
A consequence of this is that, since we're moving away from env, the interpreter path is determined only at build time. In theory, if this path is changed post-installation then the program must be rebuilt. I tested on my machine and the meson command that returns the interpreter path,
import('python').find_installation().full_path()
, returned/usr/bin/python3
, which should default to any python 3 interpreter. So in reality this is stable enough, so I think this should be no problem.