As I said. Everybody here wants something different.
I am only concerned with allowing each of you to be able to provide a
proof concept of what you want and not commit to implement any change
in web2py that will be restrictive in the long term.
When I use the word "plugins" I just mean these: htt
On Mar 15, 11:37 am, Thadeus Burgess wrote:
> Why should we call it something different when the rest of the open
> source community views it the same as we do? I mean, that is where we
> got the definition of plugin, is from other open source projects.
Thadeaus is hitting the same mark we have h
Why should we call it something different when the rest of the open
source community views it the same as we do? I mean, that is where we
got the definition of plugin, is from other open source projects.
Iin my research of pluggable systems you have the following architecture.
Base System -> The
I think I good exercise (for all of us) would be to try create an
empty "plugins" app an try to write plugins that go in there but can
be called from other apps and see what difficulty we encounter. The
current plugins will not work this way because of the models. Shared
plugins should prob
Ok Thadeus, Massimo,
Maybe I'm wrong with my understanding of the plugins system.
This time, I wasn't talking about folder locations or hooks, but the
relation between plugins and apps portability (as a feature).
I will try to get deeper in the plugin system, really I'm not an expert
programmer
Alex,
once more let me clarify. I am not opposing your proposal. I am just
saying that the proposal is vague because (as far as I understand you)
what you ask can already be done. I just have never posted an example
because I do not like it. The fact I do not like it does not mean I
want to preven
Thadeus is right. We have gone over this before. We should use the
work plugins ONLY for the current mechanism and use a more specific
name for other types of objects people now refer to as plugins.
When I think about hooks I think of a CMS app for example and I would
like to see a subset of curre
> plugins as they require by some kind of "plugin panel" or so... In deed,
> that is the meaning of "plug-ins", isn't it?
> But you must to share the plugins to be portable (as you say) maybe we are
> not talking about plugins at all...(but components).
Massimo's definition of a plugin is not the
El 15/03/2010 10:40, mdipierro escribió:
I understand the argument. Each of the system have pros and cons.
If a plugin resides outside the app you have these problems:
1) app would not be portable because plugins would not be packages
with it
I heard this argument many times from you Massi
I understand the argument. Each of the system have pros and cons.
If a plugin resides outside the app you have these problems:
1) app would not be portable because plugins would not be packages
with it
2) there would be problems if different apps require different
versions of the same plugins
Any
On Mar 13, 4:25 pm, mdipierro wrote:
> If I understand you are asking for a web2py level plugin system vs an
> app level plugin system. This has nothing to do with relocation of
> plugins under an app subfolder. Am I correct?
Well maybe but consider the following
pseudo ls
/app1/.cvs
/app1/con
Hi Massimo,
For me, the framework level plugins aren't plugins for apps directly...
(as their name say) in the sense that are low level plugins to install
by a developer and only one time in your system (not one time for each
application). The example I wrote it's a valid example, ie. and
ext
I have these questions for even normal plugins.
What If I make a plugin called `plugin_aptimizor`, that iterates
through my db and creates an optimized search index.
So later I have `plugin_comments`, but oh, I want my comments to be
part of this search index... but the search index plugin does n
In my view web2py level plugins open the doors to a lot of
portability and incompatibility problems. That is what web2py tries to
avoid by making every app complete.
On Mar 13, 11:37 am, Thadeus Burgess wrote:
> When would an app level plugin get executed?
>
> What If I have code I want to execu
When would an app level plugin get executed?
What If I have code I want to execute AFTER plugins?
What if I need a plugin to execute after another plugin, how do you
control this?
-Thadeus
On Sat, Mar 13, 2010 at 9:25 AM, mdipierro wrote:
> If I understand you are asking for a web2py level
If I understand you are asking for a web2py level plugin system vs an
app level plugin system. This has nothing to do with relocation of
plugins under an app subfolder. Am I correct?
On Mar 13, 5:36 am, selecta wrote:
> If it is possible I am in favor of relocating plug-ins to an extra
> folder
If it is possible I am in favor of relocating plug-ins to an extra
folder since this would ease my development a lot.
I develop plug-ins for multiple apps (e.g. a tracker plug-in) and I
use version control. Right now I have to decide which project is
taking control of developing the plug-in. It wor
I think this is a different issue. If you relocate plugins but you
still have all code in plugins//models/.py then they
would work no differently than now (they would be executed in
alphabetical order with the plugin name). To do what you ask you would
have to put plugin code in modules and import
If all plugins are designed to be class-like, then your example of
plugins just need to inherit.
The only reason I would be in support for logically changing the
location of plugins is the one of dependencies.
Meaning, if you have to specify to web2py when to load a plugin, and
in what order... i
The problem with framework level plugins is that if you pack the app
and unpack somewhere else then it will not work without the "framework
level" plugin installed separately. I do not think that is something
to encourage. Moreover different apps may reply on different versions
of the plugin and/or
Ok Massimo,
I agree with you in it makes no sense to rewrite a lot of web2py code.
Apart from that argument in favor, there is another I don't know if it
would be satisfied right now with plugin_name.py convention:
-Imagine you write a *framework level plugin* to subsitute auths (or
whatever
Just to clarify it:
Do we able to conservate my app (rewrited/extended) auth module/model,
working alongside "superAuth" thadeus plugin, discarding your framework
plugin and system Auth default one?
Alex
El 12/03/2010 15:31, Alex Fanjul escribió:
Ok Massimo,
I agree with you in it makes no s
The location of plugins is not a backward compatibility issue. From
that point of view, we could relocate plugin files.
The reason I do not want to do is that it is an implementation issue
that requires rewriting a lot of web2py code (particularly for the
bytecode-compile functionality), that will
Hi Massimo,
I haven't said that plugins should have to depend on others, but they
should be able to access/play with others to make a trully plugins
central network, the dependencies are resoluble at highly level with an
exposed convention API like:
plugin_most_active_users.requires=['commen
I agree with most of what you say.
99.99% of apps use a single database and so will plugins. This is
because they needs auth to do anything meaningful.
I do not think it is a good idea to have plugins that depend on each
other. dependencies are a mess to manage. In any language and any OS I
ever
Personally, my more general concern was how to control which resources
are available to plugins. I use web2py at work everyday in a true
'enterprise' setting. It is wired to several mission critical
databases. The table schemas cannot be altered by plugins. These
databases are separate from auth d
26 matches
Mail list logo
