[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