On Tue, May 5, 2009 at 1:57 AM, Ian Bicking i...@colorstudy.com wrote:
Not strong, but I have a few issues with how they are currently defined:
* There's the issue of activated and unactivated eggs, of course, but I
guess that will be moot since there's no activation with just distutils?
Yes
2009/5/5 P.J. Eby p...@telecommunity.com:
At 06:57 PM 5/4/2009 -0500, Ian Bicking wrote:
* I'm uncomfortable with the way entry points are scanned. I haven't
looked close enough to back it up with numbers, but I think there's a
noticeable performance degradation when the number of installed
On May 5, 2009, at 4:49 AM, Tarek Ziadé wrote:
On Tue, May 5, 2009 at 1:57 AM, Ian Bicking i...@colorstudy.com
wrote:
Not strong, but I have a few issues with how they are currently
defined:
* There's the issue of activated and unactivated eggs, of course,
but I
guess that will be moot
On Tue, May 5, 2009 at 1:57 PM, Doug Hellmann doug.hellm...@gmail.com wrote:
If I have to turn on the plugin, then what benefit does an entry point
registry give me?
I don't understand this sentence, since you say later that you want the user to
manually turn a plugin on for an application
On May 5, 2009, at 8:15 AM, Tarek Ziadé wrote:
On Tue, May 5, 2009 at 1:57 PM, Doug Hellmann
doug.hellm...@gmail.com wrote:
If I have to turn on the plugin, then what benefit does an entry
point registry give me?
I don't understand this sentence, since you say later that you want
the
On May 5, 2009, at 9:33 AM, Tarek Ziadé wrote:
On Tue, May 5, 2009 at 2:41 PM, Doug Hellmann
doug.hellm...@gmail.com wrote:
I am confused with the role of this man in the middle. In my mind
there are plugins on one side,
and host applications that consumes them if they wish on they
other
At 08:41 AM 5/5/2009 -0400, Doug Hellmann wrote:
I don't want new functionality available to an application just
because someone has permission to install a package somewhere in the
PYTHONPATH. I would rather have plugins added to an app through an
explicit configuration step of some sort.
On May 5, 2009, at 10:38 AM, P.J. Eby wrote:
At 08:41 AM 5/5/2009 -0400, Doug Hellmann wrote:
I don't want new functionality available to an application just
because someone has permission to install a package somewhere in the
PYTHONPATH. I would rather have plugins added to an app through
On Tue, May 5, 2009 at 4:29 PM, Doug Hellmann doug.hellm...@gmail.com wrote
I don't think I understand the difference between the step you're calling
discover, scanning the registry, and actually loading the plugin. Does
discovering the plugin involve importing any of its code?
No, like
2009/5/5 Sebastien Binet seb.bi...@gmail.com:
hi,
That allows people to create their own plugins in separate packages,
and use them by tweaking the configuration
file. The only think that entry point provided here is an automatic
registration at installation time of the rss plugins,
so my
On May 5, 2009, at 11:05 AM, Tarek Ziadé wrote:
On Tue, May 5, 2009 at 4:29 PM, Doug Hellmann
doug.hellm...@gmail.com wrote
a configuration file that reunites all entry points an application
uses. For the Atomisator example:
[atomisator.reader]
rss = somepackage.somemodule:MyPluginClass
On Tue, May 05, 2009 at 05:05:28PM +0200, Tarek Ziadé wrote:
On Tue, May 5, 2009 at 4:29 PM, Doug Hellmann doug.hellm...@gmail.com wrote
a configuration file that reunites all entry points an application
uses. For the Atomisator example:
[atomisator.reader]
rss =
At 09:27 PM 5/5/2009 +0100, Floris Bruynooghe wrote:
But how can a python setup.py install know where to find this
configuration file to add it's plugin?
It doesn't. The whole point of having two stages -- discovery and
activation -- is that discovery is an automatic side-effect of
Any ideas on this? Phillip?
On Fri, May 1, 2009 at 5:07 PM, Ian Bicking i...@colorstudy.com wrote:
So, a bit of a problem came up with pip and namespace packages. Here's my
understanding of what's going on:
When you install a namespace package with pip, it uses install
At 04:35 PM 5/5/2009 -0500, Ian Bicking wrote:
Any ideas on this? Phillip?
On Fri, May 1, 2009 at 5:07 PM, Ian Bicking
mailto:i...@colorstudy.comi...@colorstudy.com wrote:
So, a bit of a problem came up with pip and namespace
packages. Here's my understanding of what's going on:
When
Tarek Ziadé ziade.ta...@gmail.com writes:
I think is simpler with the somepackage.somemodule:MyPluginClass notation
This is how setuptools does roughly:
parts = somepackage.somemodule:MyPluginClass.split(':')
[…]
Using the standard import notation is no more difficult:
parts =
At 12:03 PM 5/6/2009 +1000, Ben Finney wrote:
I don't see any advantage, in the context of this discussion, to
having an additional, incompatible naming for full-path-to-a-class.
Setuptools doesn't limit an entry point to being a class, function,
or other top-level name within a module. It
17 matches
Mail list logo
