Plugin System for Pyramid? Howto?
Lukasz Szybalski
I was wondering how can I build a plugin for pyramid, that would be as
easy to install and setup as
easy_install myplugin
in development.ini add
[components]
myplugin.* = enabled
or if my plugin was called "admin"
[components]
admin.* = enabled
http://martyalchin.com/2008/jan/10/simple-plugin-framework/
How to declare a mount point for plugins in pyramid?
How to register a plugin at a particular mount point in pyramid?
How is pyramid system retrieving the plugins that have been registered?
Thanks,
Lucas
Jonathan Vanasco
response , but I would look into these elements that I've encountered
in the past few months:
Pyramid has Event Subscribers:
http://pyramid.readthedocs.org/en/latest/api/events.html
There are also "hooks"
http://pyramid.readthedocs.org/en/latest/narr/hooks.html
and "tweens"
http://pyramid.readthedocs.org/en/latest/narr/hooks.html#registering-tweens
You can extend the configuration quite easily with "includeme"
http://pyramid.readthedocs.org/en/latest/narr/extconfig.html?highlight=includeme
Chris McDonough
You're probably going to want to investigate Pyramid's existing plugin
system before creating another one:
- C
Jonathan Vanasco
On Mar 18, 12:07 pm, Chris McDonough <chr...@plope.com> wrote:
> You're probably going to want to investigate Pyramid's existing plugin
> system before creating another one:
so excited for the forthcoming updated docs.
Lukasz Szybalski
Great!
Is there a "sample" plugin that I could use as a reference. For
example a plugin:
/whoamI
or
/addressbook (/add/edit/delete aka /addressbook/add)
or takes something from a database, and displays it in a different way?
I checked out the pyramid_tm I see how alchemy scaffold is adding it,
but I couldn’t see how its being called, or how data and views flows
between.
Thanks,
Lucas
Chris McDonough
Not really, sorry. Included things can add views.
> I checked out the pyramid_tm I see how alchemy scaffold is adding it,
> but I couldn’t see how its being called, or how data and views flows
> between.
pyramid.includes = pyramid_tm is in the .ini file.
- C
Mike Orr
So it sounds like Lukasz is asking for a way to make a view with
customizable output. I can see a possibility for this if the view is
written to use "something" that can be overridden. I'm not sure where
to go from there, or what kind of plugin mechanism would be suitable.
Can overriding assets be used for more than just static files? Or
would ZCA be useful in this case (and not overkill)?
Lukasz, when you have a more precise specification of the kind of
plugin articile you want, you can add it to the TODO page in the
Pyramid Cookbook or file a bug report on it. The more precise you make
the request (with a use case and which kind(s) of plugin systems), the
more likely somebody will write it.
--
Mike Orr <slugg...@gmail.com>
Chris McDonough
> So it sounds like Lukasz is asking for a way to make a view with
> customizable output. I can see a possibility for this if the view is
> written to use "something" that can be overridden. I'm not sure where
> to go from there, or what kind of plugin mechanism would be suitable.
> Can overriding assets be used for more than just static files? Or
> would ZCA be useful in this case (and not overkill)?
ZCA is probably not really useful here.
What I think Lukasz is asking for is an example of how to use the
existing include() machinery to include some configuration that
registers one or more views. That's just a matter of:
def includeme(config):
config.add_view(...)
if __name__ == '__main__':
config = Configurator()
config.include(includeme)
But I think he wants to see a more complicated example that does
something else. I don't really know.
> Lukasz, when you have a more precise specification of the kind of
> plugin articile you want, you can add it to the TODO page in the
> Pyramid Cookbook or file a bug report on it. The more precise you make
> the request (with a use case and which kind(s) of plugin systems), the
> more likely somebody will write it.
Talking about "plugin systems" is probably overeager here. I think what
Lukasz may need to do is to enumerate the goals implied by his use of
the term "plugin system" and maybe describe one (read: not all!) of
those goals in concrete detail so we can provide an example of how he
might accomplish it using the existing machinery.
- C
Mike Orr
> On Mon, 2012-03-19 at 11:04 -0700, Mike Orr wrote:
>
>> So it sounds like Lukasz is asking for a way to make a view with
>> customizable output. I can see a possibility for this if the view is
>> written to use "something" that can be overridden. I'm not sure where
>> to go from there, or what kind of plugin mechanism would be suitable.
>> Can overriding assets be used for more than just static files? Or
>> would ZCA be useful in this case (and not overkill)?
>
> ZCA is probably not really useful here.
>
> What I think Lukasz is asking for is an example of how to use the
> existing include() machinery to include some configuration that
> registers one or more views.
Yes, it depends on whether he wants to add views or customize existing
views. I thought his "takes something from a database, and displays it
in a different way" meant he wants to customize existing views.
--
Mike Orr <slugg...@gmail.com>
Chris McDonough
Yeah.
Note that due to the way configuration conflict resolution works, if you
have a project that has an includeme like this:
def includeme(config):
config.add_route('bar', '/bar')
config.add_view('myproject.foo', route_name='bar')
.. and you do this ..
config = Configurator()
config.include(myproject.includeme)
config.add_view('thisproject.foo', route_name='bar')
.. the 'thisproject.foo' view will override the 'myproject.foo' view (it
is "more specific"; configuration statements that take place "closer to
the configurator" aka "at a lower include level" will override one that
takes place at a greater include level. This is documented in
http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/advconfig.html#automatic-conflict-resolution
The rest of the information in that chapter describes other facilities
which allow for overriding of configuration statements, such as
strategically using config.commit().
The asset override stuff also allows you to switch templates for a given
view, if that's all you need. It's documented at
http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/assets.html#overriding-assets
- C
Mike Orr
> The asset override stuff also allows you to switch templates for a given
> view, if that's all you need. It's documented at
> http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/assets.html#overriding-assets
... if you're using an asset spec for the template. If you're using a
filename and depending on the Mako search path, would this still
apply?
PS. When I read in the docs that you could make a Mako application
entirely with asset specs, you wouldn't need the Mako search path, but
when I tried it I couldn't get it to work. I may have had the wrong
asset syntax, or maybe it was just because my templates have an
inherited site template.
In any case, I don't think asset specs for Mako will become popular
unless there's a way to shorten the syntax.
'renderer="myapp:templates/abc.mako"' takes up so much space it forces
you to split the @view_config to multiple lines, which is not the case
in its TurboGears and CherryPy predecessors. If I just specify
"/abc.mako", it seems to not consider it an asset spec.
--
Mike Orr <slugg...@gmail.com>
Chris McDonough
> On Mon, Mar 19, 2012 at 11:49 AM, Chris McDonough <chr...@plope.com> wrote:
> > The asset override stuff also allows you to switch templates for a given
> > view, if that's all you need. It's documented at
> > http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/assets.html#overriding-assets
>
> ... if you're using an asset spec for the template. If you're using a
> filename and depending on the Mako search path, would this still
> apply?
>
> PS. When I read in the docs that you could make a Mako application
> entirely with asset specs, you wouldn't need the Mako search path, but
> when I tried it I couldn't get it to work. I may have had the wrong
> asset syntax, or maybe it was just because my templates have an
> inherited site template.
Dunno but Ben added support for asset specs to the Mako stuff, he may
know.
> In any case, I don't think asset specs for Mako will become popular
> unless there's a way to shorten the syntax.
> 'renderer="myapp:templates/abc.mako"' takes up so much space it forces
> you to split the @view_config to multiple lines, which is not the case
> in its TurboGears and CherryPy predecessors. If I just specify
> "/abc.mako", it seems to not consider it an asset spec.
If I had it to do all over again, I would not provide support for Mako
search paths at all and do it how Chameleon bindings do it (everything
is an asset spec there, and relative filenames are asset specs relative
to the package they're defined in). C'est la vie.
- C
Robert Forkel
it easier to provide support for plugins to override templates by
specifying an additional asset spec for the mako_directories config
setting. it's a bit less flexible because you can only override
templates by ones with the same relative path, but i think it's also
more transparent than override_asset.
> --
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
> To post to this group, send email to pylons-...@googlegroups.com.
> To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
>
Lukasz Szybalski
> On Mon, 2012-03-19 at 11:04 -0700, Mike Orr wrote:
>
>> So it sounds like Lukasz is asking for a way to make a view with
>> customizable output. I can see a possibility for this if the view is
>> written to use "something" that can be overridden. I'm not sure where
>> to go from there, or what kind of plugin mechanism would be suitable.
I guess I'm just looking for example a hello world plugin
(http://trac-hacks.org/wiki/HelloWorldPlugin) and how do I go about
designing it for pyramid.
1. You start up your scaffold "alchemy" app and start adding plugins
to it to help you get to a point where you start building what you
need.
2. How do you add /admin page that allows you to add/edit/delete
records in database? Why wouldn't I be able to just download this
plugin for pyarmid and enable it. Or write a plugin so I could reuse
it in all my apps.
3. How would one go about building a /admin page similar to trac that
allows you to for example view a list of plugins installed "included".
"Example of how to use the existing include() machinery to include
some configuration that registers one or more views" is probably what
I'm looking for exactly. I will have to research that to see how one
would build admin page that registers views that access your database
and allow you to add/edit/delete records. Create some docs, and
hopefully one could use that as a example to lets say build
"permission editing" or "auto build views based on what is in
database"..etc
I've created a ticket# for this : https://github.com/Pylons/pyramid/issues/507
Let me know if somebody from pyramid team is able to build a sample
plugin in less then an hour that I could look at code and start
learning.
Thank you,
Lucas
>> Can overriding assets be used for more than just static files? Or
>> would ZCA be useful in this case (and not overkill)?
>
> ZCA is probably not really useful here.
>
> What I think Lukasz is asking for is an example of how to use the
> existing include() machinery to include some configuration that
> registers one or more views. That's just a matter of:
>
> def includeme(config):
> config.add_view(...)
>
> if __name__ == '__main__':
> config = Configurator()
> config.include(includeme)
>
> But I think he wants to see a more complicated example that does
> something else. I don't really know.
>
>> Lukasz, when you have a more precise specification of the kind of
>> plugin articile you want, you can add it to the TODO page in the
>> Pyramid Cookbook or file a bug report on it. The more precise you make
>> the request (with a use case and which kind(s) of plugin systems), the
>> more likely somebody will write it.
>
> Talking about "plugin systems" is probably overeager here. I think what
> Lukasz may need to do is to enumerate the goals implied by his use of
> the term "plugin system" and maybe describe one (read: not all!) of
> those goals in concrete detail so we can provide an example of how he
> might accomplish it using the existing machinery.
>
> - C
>
>
> --
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
> To post to this group, send email to pylons-...@googlegroups.com.
> To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
>
Chris McDonough
> On Mon, Mar 19, 2012 at 1:13 PM, Chris McDonough <chr...@plope.com> wrote:
> > On Mon, 2012-03-19 at 11:04 -0700, Mike Orr wrote:
> >
> >> So it sounds like Lukasz is asking for a way to make a view with
> >> customizable output. I can see a possibility for this if the view is
> >> written to use "something" that can be overridden. I'm not sure where
> >> to go from there, or what kind of plugin mechanism would be suitable.
>
>
> I guess I'm just looking for example a hello world plugin
> (http://trac-hacks.org/wiki/HelloWorldPlugin) and how do I go about
> designing it for pyramid.
>
>
> 1. You start up your scaffold "alchemy" app and start adding plugins
> to it to help you get to a point where you start building what you
> need.
> 2. How do you add /admin page that allows you to add/edit/delete
> records in database? Why wouldn't I be able to just download this
> plugin for pyarmid and enable it. Or write a plugin so I could reuse
> it in all my apps.
> 3. How would one go about building a /admin page similar to trac that
> allows you to for example view a list of plugins installed "included".
You're likely to be disappointed at things that Pyramid itself or things
that require only Pyramid will provide here. Pyramid doesn't know
anything about databases at all.
That said, systems built on top of Pyramid like Ptah
(http://ptahproject.org) and Kotti
(http://danielnouri.org/notes/2011/11/30/how-to-write-an-add-on-for-the-kotti-cms/) do provide enough "rails" for this to be possible.
> "Example of how to use the existing include() machinery to include
> some configuration that registers one or more views" is probably what
> I'm looking for exactly. I will have to research that to see how one
> would build admin page that registers views that access your database
> and allow you to add/edit/delete records. Create some docs, and
> hopefully one could use that as a example to lets say build
> "permission editing" or "auto build views based on what is in
> database"..etc
All of that stuff is complete space-shuttle as far as Pyramid is
concerned.
You should probably adjust how you're thinking about this. What you're
*asking for* are "plugins". But what you actually *need* are
applications.
Pyramid is a platform on which you can build *an* application. An
application built on top of Pyramid might itself allow for pluggable
subapplications, and it might reuse Pyramid's include() functionality to
allow those things to be plugged into it. This is what Kotti and Ptah
do.
> I've created a ticket# for this : https://github.com/Pylons/pyramid/issues/507
> Let me know if somebody from pyramid team is able to build a sample
> plugin in less then an hour that I could look at code and start
> learning.
Anything I create is probably just going to disappoint you, but maybe
someone else is up for it. I'd look into Kotti or Ptah if I were you.
- C
Chris McDonough
> That said, systems built on top of Pyramid like Ptah
> (http://ptahproject.org) and Kotti
Sorry, apparently that URL should be
http://readthedocs.org/docs/ptahproject/en/latest/
tonthon
pyramid_formalchemy's way of building a ''plugin'' :
http://pypi.python.org/pypi/pyramid_formalchemy
Le 21/03/2012 05:04, Lukasz Szybalski a �crit :
Mike Orr
> On Mon, Mar 19, 2012 at 1:13 PM, Chris McDonough <chr...@plope.com> wrote:
>> On Mon, 2012-03-19 at 11:04 -0700, Mike Orr wrote:
>>
>>> So it sounds like Lukasz is asking for a way to make a view with
>>> customizable output. I can see a possibility for this if the view is
>>> written to use "something" that can be overridden. I'm not sure where
>>> to go from there, or what kind of plugin mechanism would be suitable.
>
>
> I guess I'm just looking for example a hello world plugin
> (http://trac-hacks.org/wiki/HelloWorldPlugin) and how do I go about
> designing it for pyramid.
>
>
> 1. You start up your scaffold "alchemy" app and start adding plugins
> to it to help you get to a point where you start building what you
> need.
It revolves around what you mean by a "plugin". As I said, there's no
universal definition, and people have widely differing ideas about
what plugins are and what kinds of things they should do. Pyramid has
nothing called a plugin, although the word is sometimes used for its
ZCA (Zope Component Architecture) interface. It has several things
that allow you to insert functionality into an application --
includes, asset overriding, entry points, custom renderers, the
resource tree, etc -- these could all fit the basic definition of a
plugin.
> 2. How do you add /admin page that allows you to add/edit/delete
> records in database? Why wouldn't I be able to just download this
> plugin for pyarmid and enable it. Or write a plugin so I could reuse
> it in all my apps.
We (Pylons/Pyramid) have long wished for an easy-to-install CRUD
interface / admin interface. The only one that has been written is in
Ptah. FormAlchemy gives you building blocks to make such a thing.
Theoretically it would be possible to "include" a package mounted on
/admin that does this, if such a package existed.
> 3. How would one go about building a /admin page similar to trac that
> allows you to for example view a list of plugins installed "included".
That depends on what a plugin is. My first point.
As far as I know, Pyramid does not have a list of prior includes, or a
way to distinguish relevant includes (from your perspective) vs other
includes. You could write something that keeps a list of relevant
includes in 'settings'.
> "Example of how to use the existing include() machinery to include
> some configuration that registers one or more views" is probably what
> I'm looking for exactly. I will have to research that to see how one
> would build admin page that registers views that access your database
> and allow you to add/edit/delete records. Create some docs, and
> hopefully one could use that as a example to lets say build
> "permission editing" or "auto build views based on what is in
> database"..etc
It sounds like you're on your way to building an includible CRUD
interface. Ptah may have some code you can start from, although it's
intertwined with how Ptah manages sessions/engines.
I'm not sure I would call it a plugin though. I think of it more as a
view bundle. (A collection of views, with whatever templates, routes,
models, and static files it needs.)
--
Mike Orr <slugg...@gmail.com>