[Qgis-developer] Changes to python/utils.py

[Larry Shaffer]

On Tue, May 29, 2012 at 1:01 PM, Martin Dobias <wonder.sk at gmail.com> wrote:
> Hi Larry
>
> On Sat, May 26, 2012 at 2:14 AM, Larry Shaffer <larrys at dakotacarto.com> wrote:
>>
>> 1) Python exceptions - add lightweight debug output
>>
>> [...]
>
> I would really like to see that functionality - in the early times I
> was happy with just a traceback - a full report with values of locals
> would be surely better :-)
> We could avoid adding new tabs, everything could be on one page (using
> QWebView and some CSS). The table with variables for each frame could
> be collapsible and inline with traceback frames - e.g. similar to how
> django error pages look like [4]. Also, it would be good to have a
> button to easily save the error report to allow users easily attach
> error details to bug reports.
>
> [4] http://linkaider.com/wp-content/uploads/2009/12/django-error.jpg

Martin, thanks for the input. django-like error output looks ideally
suited for this proposed change. There is a lot to chew on in django's
debug.py file [0]. It has the HTML template as well as more updated
code for lightweight debug output.

I suppose a single, self-contained HTML file (one displayed?) could be
saved to disk for the error report, keeping it simple.

Using QWebViews for this type of info also follows suit with similar
work Tim posted to his blog [1].

[0] https://github.com/django/django/blob/master/django/views/debug.py
[1] http://linfiniti.com/2011/11/more-on-qgis-desktop-web-fusion/


>> 2) Module import - add deeper module tracking/reloading
>>
>> There has recently been work on a module [2][3] that recursively
>> tracks and reloads dependent module imports in a way that I think is a
>> little more robust and flexible than the current method in
>> python/utils.py.
>> [...]
>> This correct-dependency-order recursive reload not only might allow
>> plugins to be fully reloaded live, even with in-module sys.path
>> adjustments, but also *retain* selected module states (see [2]
>> __reload__() description). This might mean a LOT less QGIS relaunches
>> during plugin development.
>
> I am a bit afraid of the live code reloading. While I understand that
> it sounds good that it would be possible to retain module state, I
> think there are various cases where this would fail, e.g. if a module
> fails to reload (syntax error?) or the changes from last iteration
> were more significant (change of class structure?). Also, the
> __reload__() callback would need to be done very carefully as it could
> cause even more trouble.
>
> I would like to keep the "hard" reload as a default since you can
> trust it to do its work. The "live" reload could be eventually added,
> too, as an option for the brave ones :-)

By 'keep the "hard" reload ' do you mean the current reload function,
or the basic reload function of a reloader.py-upgraded utils.py?

By 'live' I'm guessing you are referring to the 'automatic detection
of module changes,' i.e. monitor.py . I don't think that live
reloading would be that useful for QGIS plugin development. I'm mostly
looking at this module's functionality as a more complete basic plugin
reloader. Live reloading and __reload__() functions are secondary, and
will probably cause more problems than they solve.


> Btw. Plugins should not alter sys.path. I know that some do it, but
> that's a bad idea.

I think sometimes this is necessary. For example, my Plugin Editor
plugin contains several third-party packages that only work when on a
sys.path. Plugin maintenance/support-wise, I would rather know the
embedded packages, though maybe outdated, will continue to work, and
new versions can be tested before being upgraded.

Regards,

Larry