[Twisted-Python] Multiple plugins in "twistd"

[Moshe Zadka]

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)
[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.
[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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20150520/dcd432b5/attachment-0002.html>