[Twisted-Python] Multiple plugins in "twistd"

exarkun at twistedmatrix.com exarkun at twistedmatrix.com
Wed May 20 05:08:32 MDT 2015


On 02:41 am, zadka.moshe at gmail.com wrote:
>OK, so let me once again enumerate the tickets I'm going to open, 
>because
>it seems like we're reaching consensus:
>
>[1] PROVIDES (pretty much as written: exarkun -- the idea is to walk up 
>the
>hierarchy and then back down, so I did mean IService -- go up until you
>find a root, then go down and get all descendents)

Oops.  You can't get children *or* a parent from IService.  But you can 
at least get children from IServiceCollection.

Jean-Paul
>[2] 3538 -- will do it with a flag to turn on .tac + plugin
>[2.1] I'm assuming the deprecation dance is "flag to turn on" -> "flag 
>to
>turn on + warn if .tac+plugin and no flag" -> "make flag no-op" -> 
>"warn on
>flag" -> "remove flag". If someone doesn't want this dance, please let 
>me
>know preferred alternatives.

Glyph referred to the alternative.  Here it is fully spelled out:

https://twistedmatrix.com/trac/wiki/CompatibilityPolicy#ProcedureforExceptionstothisPolicy

Alternatively, do it the nice way but not *quite* as you described:

  * Make a new flag like --python but that combines with plugins.
  * Deprecate --python
  * Remove --python

Three steps instead of five and only bother the user once instead of 
twice.

Thanks!

Jean-Paul
>[3] MAKE -- API for "createServiceFromNameAndOptions" (basically,
>compose-as-a-library)
>[4] COMPOSE (implements twistd_compose plugin)
>
>I think there's at least rough consensus that these four pieces are 
>useful,
>even if there's still some disagreement on the details, so maybe the 
>next
>step is to open the three to-be-opened tickets, and then to discuss the
>details on the tickets. I'm going to do the ticket opening tomorrow, 
>and
>maybe even work on them during the SF Python Meetup (anyone in SF -- 
>you
>should [a] go and [b] say hi also [c] optionally, help me with that).
>
>If anyone has serious objections to this plan, let me know!
>
>Thanks,
>Moshe Z.
>
>On Tue, May 19, 2015 at 2:35 PM Glyph <glyph at twistedmatrix.com> wrote:
>>
>> > On May 19, 2015, at 14:01, Tom Prince <tom.prince at ualberta.net> 
>>wrote:
>> >
>> > Glyph <glyph at twistedmatrix.com> writes:
>> >
>> >> You could also find some other way to split the argument list but 
>>"+"
>>doesn't seem particularly obscure in this context to me.  (If there's
>>really a need to pass a literal "+" to a plugin we could add an 
>>escaping
>>syntax as well.)
>> >
>> > I think if we are adding syntax, then we should also add escaping at 
>>the
>> > same time.
>> >
>> > On a related note, when designing this kind of syntax, I think it is
>> > often valuable to explictly leave some of the space as an explict 
>>error,
>> > to leave freedom to extend the syntax in the future.
>> >
>> > I wonder if there is any value in having a syntax that is nestable. 
>>I
>> > don't see any specific use case, but I can imagine wanting ot pass
>> > options to `compose` that are scoped to an individual plugin that it 
>>is
>> > loading. And then, maybe you want to nest things so that those 
>>options
>> > apply to a subset of plugins, which might naturally be implemented 
>>as
>> > compos of a compose.
>> >
>> > The suggestions in the last paragraph are perhaps somewhat 
>>contrived,
>> > and certainly not something that should be *implemnted* in a first 
>>(or
>> > even second pass). But considering the possiblity, and then picking 
>>a
>> > syntax that might allow those kinds of extension (and then explictly
>> > making the extension syntax an error) gives us the ability to add 
>>those
>> > features without breaking backwards compatibility.
>>
>>We can un-escape '\+' as a token just fine, and if we do that, all of 
>>the
>>weird use-cases you just described are possible.  I can't think of any
>>options I'd want to pass to 'compose' myself, but it would be easy 
>>enough
>>to add some flags to its parser.
>>
>>-g
>




More information about the Twisted-Python mailing list