Gustavo writes about python, it’s webbrowser module, os.fork and parsing bugreports from our BTS via html. This all sound very familiar, so here are some hints from me:
- You don’t have to fork a new process just to call a browser, try
thread.start_new_thread(webbrowser.open, (url,)). No need to clean up the child process after it has finished, just call start_new_thread with the function and it’s parameters and forget it.
- Python’s webbrowser module is nice, but it often fails to find the right browser. The problem is to find the users (read: not the system’s) default browser across the different desktop environments. xdg-open from the package xdg-utils (from freedesktop.org) seems to do a very good job. ~~Rng doesn’t use it yet, but I’m definitely planning to replace the webbrowser call with xdg-open.~~ Rng uses it and falls back to python’s webbrowser.open()-call if xdg-open failed.
- If your project suffers from changes in the html code of our BTS,
try SOAP instead. It provides all the infos in machine readable
format and also comes with backwards compatibility: the namespace
for debbug’s SOAP interface is
Debbugs/SOAPwhich always calls the latest versions of the remote functions. But you can also use
Debbugs/SOAP/V1(Version 1 currently matches
Debbugs/SOAP). This will ensure that changes in debbugs SOAP interface don’t affect your implementation.