TracDeveloperPlugin

1 view
Skip to first unread message

Christopher Lenz

unread,
Feb 13, 2008, 7:05:18 AM2/13/08
to trac...@googlegroups.com
Hey all,

I spent some time hacking on the TracDeveloperPlugin yesterday,
cleaning it up as well as adding a fancy replacement for good ole ?
hdfdump, plus integration with API documentation.

For screenshots and more info, see:

<http://trac-hacks.org/wiki/TracDeveloperPlugin>

I encourage everyone working on Trac or Trac plugins to try this out
and provide feedback. Note that you currently should not enable this
plugin on Trac sites accessible to potentially untrusted users, as it
exposes a lot of internals without requiring any permission checks.
Also, the template debugger only works completely with single process
deployments (such as tracd).

Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/

Christian Boos

unread,
Feb 13, 2008, 7:56:22 AM2/13/08
to trac...@googlegroups.com
Christopher Lenz wrote:
> Also, the template debugger only works completely with single process
> deployments (such as tracd).
>

Multi-thread safe or not? i.e. should the ThreadedMixin be disabled?

-- Christian

Christopher Lenz

unread,
Feb 13, 2008, 8:42:13 AM2/13/08
to trac...@googlegroups.com

It should be mostly thread-safe (some additional locking may be
necessary in the cache purging for full robustness), but it's intended
more for local test deployments where a single person hacks away and
tests. The only part where this is relevant is the template context
data inspector, btw.

Cheers,
Chris

Christian Boos

unread,
Feb 13, 2008, 8:54:34 AM2/13/08
to trac...@googlegroups.com
Christopher Lenz wrote:
> On 13.02.2008, at 13:56, Christian Boos wrote:
>
>> Christopher Lenz wrote:
>>
>>> Also, the template debugger only works completely with single process
>>> deployments (such as tracd).
>>>
>> Multi-thread safe or not? i.e. should the ThreadedMixin be disabled?
>>
>
> It should be mostly thread-safe (some additional locking may be
> necessary in the cache purging for full robustness), but it's intended
> more for local test deployments where a single person hacks away and
> tests. The only part where this is relevant is the template context
> data inspector, btw.
>

Ok, understood. Nevertheless, the lone hacker may want to stress-test
tracd and occasionally debug the /multithreaded/ situation as well ;-)

-- Christian

Dalius Dobravolskas

unread,
Feb 15, 2008, 3:23:13 AM2/15/08
to trac...@googlegroups.com
Hello, Christopher,

> I encourage everyone working on Trac or Trac plugins to try this out
> and provide feedback.

I can just say that it works with newest trac 0.11 on Windows systems. I
have written just one plugin but in my case developer plugin is not very
useful for me.

I can't speak for every trac plugin developer but here are some ideas
that in my opinion would help a lot but they are outside of developer
plugin:

1) Show full traceback of exception by default. Currently user just gets
exception message what is not very convenient.

2) Send full traceback of exception with HTTP headers and other
available context information to specified e-mail address (pylons acts
in the same way and I find it very useful when in real system something
fails and I can fix it before it hits other users).

Regards,
Dalius

Noah Kantrowitz

unread,
Feb 15, 2008, 1:54:31 PM2/15/08
to trac...@googlegroups.com
Dalius Dobravolskas wrote:
> Hello, Christopher,
>
>
>> I encourage everyone working on Trac or Trac plugins to try this out
>> and provide feedback.
>>
> I can just say that it works with newest trac 0.11 on Windows systems. I
> have written just one plugin but in my case developer plugin is not very
> useful for me.
>
> I can't speak for every trac plugin developer but here are some ideas
> that in my opinion would help a lot but they are outside of developer
> plugin:
>
> 1) Show full traceback of exception by default. Currently user just gets
> exception message what is not very convenient.
>
Login with a TRAC_ADMIN user. The full traceback is not shown for
security reasons.

> 2) Send full traceback of exception with HTTP headers and other
> available context information to specified e-mail address (pylons acts
> in the same way and I find it very useful when in real system something
> fails and I can fix it before it hits other users).
>
Exception logging sounds like a good addition, either to a DB or email
(or both).

--Noah


signature.asc

Dalius Dobravolskas

unread,
Feb 16, 2008, 8:25:43 AM2/16/08
to trac...@googlegroups.com
Noah Kantrowitz wrote:
>> 1) Show full traceback of exception by default. Currently user just
>> gets exception message what is not very convenient.
>>
> Login with a TRAC_ADMIN user. The full traceback is not shown for
> security reasons.
That's funny part. I'm author of OpenID plugin - all the problems I get
happens before I login. The same applies to users of my plugin and all I
can offer some logging based (or similar) debugging.

Regards,
Dalius

Reply all
Reply to author
Forward
0 new messages