headers
Remy Blank | 1 Nov 02:42
Picon
Favicon

[Trac-dev] Modularizing trac-admin

While working on the multirepos branch, the need for a few additional
trac-admin commands came up. Christian suggested that trac-admin should
be modularized, so that the code for commands could be relocated to the
individual modules, in particular close to the web admin modules.

I have started working on this in:

  http://trac.edgewall.org/ticket/7770

In particular, I have specified an IAdminCommandProvider interface, a
command manager, and I have implemented the dispatch functionality and
one example of moving commands out (the config commands).

It would be great if I could get some feedback on the interface and the
general idea, before continuing. Once the interface is settled, I would
progressively move most commands to the new infrastructure.

-- Remy
Permalink | Reply | 12 comments |
headers
Noah Kantrowitz | 1 Nov 03:22
Gravatar

[Trac-dev] Re: Modularizing trac-admin


On Oct 31, 2008, at 6:42 PM, Remy Blank wrote:

> While working on the multirepos branch, the need for a few additional
> trac-admin commands came up. Christian suggested that trac-admin  
> should
> be modularized, so that the code for commands could be relocated to  
> the
> individual modules, in particular close to the web admin modules.
>
> I have started working on this in:
>
>  http://trac.edgewall.org/ticket/7770
>
> In particular, I have specified an IAdminCommandProvider interface, a
> command manager, and I have implemented the dispatch functionality and
> one example of moving commands out (the config commands).
>
> It would be great if I could get some feedback on the interface and  
> the
> general idea, before continuing. Once the interface is settled, I  
> would
> progressively move most commands to the new infrastructure.

See also: http://trac-hacks.org/browser/adminconsoleproviderpatch/0.9

One of the first things ever posted to trac-hacks ;-)

--Noah
(Continue reading)

Permalink | Reply | 7 comments |
headers
Remy Blank | 1 Nov 09:49
Picon
Favicon

[Trac-dev] Re: Modularizing trac-admin

Noah Kantrowitz wrote:
> See also: http://trac-hacks.org/browser/adminconsoleproviderpatch/0.9
> 
> One of the first things ever posted to trac-hacks ;-)

Thanks for the reference, I didn't know about that patch.

Mmmh... It doesn't seem to apply cleanly... ;-)

More seriously, this opens a few questions:

 - Should the admin commands be placed into separate components? I was
going to integrate them into either the *System components, or the admin
panels. The patch above creates separate components.

 - Should it be possible for a plugin to safely override existing
commands? I would say no, as this might make support more difficult.

-- Remy
Permalink | Reply | 6 comments |
headers
osimons | 1 Nov 10:03
Picon

[Trac-dev] Re: Modularizing trac-admin


On Nov 1, 9:49 am, Remy Blank <remy.bl...@pobox.com> wrote:
> Noah Kantrowitz wrote:
> > See also:http://trac-hacks.org/browser/adminconsoleproviderpatch/0.9
>
> > One of the first things ever posted to trac-hacks ;-)
>
> Thanks for the reference, I didn't know about that patch.
>
> Mmmh... It doesn't seem to apply cleanly... ;-)
>
> More seriously, this opens a few questions:
>
>  - Should the admin commands be placed into separate components? I was
> going to integrate them into either the *System components, or the admin
> panels. The patch above creates separate components.
>
>  - Should it be possible for a plugin to safely override existing
> commands? I would say no, as this might make support more difficult.

Interesting questions. My preference would be to split them up into
many components. That way they can be easily disabled and replaced by
other components. For instance if some permission-related plugin wants
to replace the default permission commands, it can disable that
component only and provide its own implementation for 'permission....'
handling. By having many clearly defined components, I don't think it
would not be necessary to provide support for overriding.

:::simon
(Continue reading)

Permalink | Reply | 5 comments |
headers
Noah Kantrowitz | 1 Nov 10:22
Gravatar

[Trac-dev] Re: Modularizing trac-admin


On Nov 1, 2008, at 2:03 AM, osimons wrote:

>
> On Nov 1, 9:49 am, Remy Blank <remy.bl...@pobox.com> wrote:
>> Noah Kantrowitz wrote:
>>> See also:http://trac-hacks.org/browser/adminconsoleproviderpatch/0.9
>>
>>> One of the first things ever posted to trac-hacks ;-)
>>
>> Thanks for the reference, I didn't know about that patch.
>>
>> Mmmh... It doesn't seem to apply cleanly... ;-)
>>
>> More seriously, this opens a few questions:
>>
>>  - Should the admin commands be placed into separate components? I  
>> was
>> going to integrate them into either the *System components, or the  
>> admin
>> panels. The patch above creates separate components.
>>
>>  - Should it be possible for a plugin to safely override existing
>> commands? I would say no, as this might make support more difficult.
>
> Interesting questions. My preference would be to split them up into
> many components. That way they can be easily disabled and replaced by
> other components. For instance if some permission-related plugin wants
> to replace the default permission commands, it can disable that
> component only and provide its own implementation for 'permission....'
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonas Borgström | 2 Nov 20:15
Favicon

[Trac-dev] Re: Timing for release 0.11.2


Christian Boos wrote:
> #6436 works well from my testing, but it's potentially risky (i.e. it
> might break Trac in ways I didn't foresee).
> Wider testing would be good, and as I wrote in that ticket, I'm OK to
> delay it further if needed.
> OTOH, if jonas would update to latest 0.11-stable + that patch and
> everything goes well for a few days, that could give us some more
> confidence about it.

t.e.o is now running r7646 and so far everything seems to work as 
expected.

>>  - Would it be reasonable to schedule the 0.11.2 release in the next few
>> days? I see that Christian has already prepared much of it. I have never
>> actively participated in a release, so I would need some guidance to
>> help efficiently.
>>
> 
> See http://trac.edgewall.org/wiki/TracDev/ToDo#Release0.11.2.
> Btw, don't hesitate to use that page as a scratchpad as well, I think it
> helps to see what's currently going on.

I also think 0.11.2 is in pretty good shape. For me personally a release 
this Wednesday or Thursday would work fine.

/ Jonas

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Remy Blank | 2 Nov 21:57
Picon
Favicon

[Trac-dev] Re: Modularizing trac-admin

Noah Kantrowitz wrote:
> I would put them in the same components as provide the webadmin UI.  
> Seems logical that if you want to disable (or replace) the webadmin  
> panel you would also want to remove the command.

I like the idea of replacing commands by disabling the corresponding
component. And I also think that the webadmin panel and the trac-admin
commands belong together, hopefully they will even share some code. So
I'll go this route.

Thanks for your comments.

-- Remy
Permalink | Reply | 0 comments |
headers
Remy Blank | 3 Nov 22:58
Picon
Favicon

[Trac-dev] Re: Modularizing trac-admin

osimons wrote:
> Interesting questions.

I've got one more:

 - Should the command handlers receive an "out" and an "err" parameter
as the output and error streams and use these for printing, or should
they use sys.stdout and sys.stderr instead?

   + commands can be called from a non-console context
   - all command handlers get two additional, rarely-used arguments

-- Remy
Permalink | Reply | 2 comments |
headers
Noah Kantrowitz | 4 Nov 00:04
Gravatar

[Trac-dev] Re: Modularizing trac-admin


> -----Original Message-----
> From: trac-dev <at> googlegroups.com [mailto:trac-dev <at> googlegroups.com] On
> Behalf Of Remy Blank
> Sent: Monday, November 03, 2008 1:59 PM
> To: trac-dev <at> googlegroups.com
> Subject: [Trac-dev] Re: Modularizing trac-admin
> 
> osimons wrote:
> > Interesting questions.
> 
> I've got one more:
> 
>  - Should the command handlers receive an "out" and an "err" parameter
> as the output and error streams and use these for printing, or should
> they use sys.stdout and sys.stderr instead?
> 
>    + commands can be called from a non-console context
>    - all command handlers get two additional, rarely-used arguments

I don't see why we would want to call console admin commands directly
instead of making a webadmin UI. All the interesting cases would require
elevated permissions anyway. I have code in tracforge to do all of this, as
well as rehooking stdout and stderr.

--Noah

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Remy Blank | 4 Nov 00:25
Picon
Favicon

[Trac-dev] Re: Modularizing trac-admin

Noah Kantrowitz wrote:
> I don't see why we would want to call console admin commands directly
> instead of making a webadmin UI. All the interesting cases would require
> elevated permissions anyway.

I agree. It was more a case of "it would be easy to do, so let's think
about it now rather than too late".

Thanks for your comment.

-- Remy
Permalink | Reply | 0 comments |

Gmane