Hello
Le 03/08/2010 13:09, Michael Foord a écrit :
> On 03/08/2010 09:28, M.-A. Lemburg wrote:
>> P.J. Eby wrote:
>>> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
> [idea about sqlite3 db for caching]
[distros won’t like it, the filesystem is the db]
>>> [the db is a cache, it does no
On 8/3/2010 12:33 PM, Glyph Lefkowitz wrote:
>
> On Aug 3, 2010, at 4:28 AM, M.-A. Lemburg wrote:
>
>> I don't think that's a problem: the SQLite database would be a cache
>> like e.g. a font cache or TCSH command cache, not a replacement of
>> the meta files stored in directories.
>>
>> Such a d
On Aug 3, 2010, at 4:28 AM, M.-A. Lemburg wrote:
> I don't think that's a problem: the SQLite database would be a cache
> like e.g. a font cache or TCSH command cache, not a replacement of
> the meta files stored in directories.
>
> Such a database would solve many things at once: faster access
On 03/08/2010 16:24, David Cournapeau wrote:
On Tue, Aug 3, 2010 at 11:35 PM, Michael Foord
wrote:
On 03/08/2010 15:19, David Cournapeau wrote:
On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou
wrote:
On Tue, 03 Aug 2010 10:28:07 +0200
"M.-A. Lemburg"wrote:
On Tue, Aug 3, 2010 at 11:35 PM, Michael Foord
wrote:
> On 03/08/2010 15:19, David Cournapeau wrote:
>>
>> On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou
>> wrote:
>>
>>>
>>> On Tue, 03 Aug 2010 10:28:07 +0200
>>> "M.-A. Lemburg" wrote:
>>>
>
> Don't forget system packaging tools like .d
At 01:40 PM 8/3/2010 +0200, M.-A. Lemburg wrote:
If you look at the proposal, it is really just about adding a
new data store to manage a certain package type called "plugins".
Next time around, someone will want to see support for "skins" or
"themes". Then perhaps identify "script" packages, or
On 03/08/2010 15:19, David Cournapeau wrote:
On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou wrote:
On Tue, 03 Aug 2010 10:28:07 +0200
"M.-A. Lemburg" wrote:
Don't forget system packaging tools like .deb, .rpm, etc., which do not
generally take kindly to updating such things. For be
At 10:28 AM 8/3/2010 +0200, M.-A. Lemburg wrote:
Since you are into comparing numbers, you might want to count
the number of Zope plugins that are available on PyPI and its plugin
system has been around much longer than setuptools has been.
I don't think that proves anything, though.
Actually,
> There is a tension between the two approaches: either you want
> "auto-discovery", or you want a system with explicit registration and
> only the registered plugins would be visible to the system.
I think both are necessary. A discovery API should be available, but the
library or application sh
On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou wrote:
> On Tue, 03 Aug 2010 10:28:07 +0200
> "M.-A. Lemburg" wrote:
>> >
>> > Don't forget system packaging tools like .deb, .rpm, etc., which do not
>> > generally take kindly to updating such things. For better or worse, the
>> > filesystem *is*
On 2 Aug, 2010, at 2:03, Tarek Ziadé wrote:
> On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord
> wrote:
>> On 02/08/2010 00:46, Tarek Ziadé wrote:
>>>
>>> [snip...]
I don't think that unittest would use a distutils2 (or pkgutil) supplied
API
for activation.
>>>
>>> But
On Tue, 03 Aug 2010 10:28:07 +0200
"M.-A. Lemburg" wrote:
> >
> > Don't forget system packaging tools like .deb, .rpm, etc., which do not
> > generally take kindly to updating such things. For better or worse, the
> > filesystem *is* our "central database" these days.
>
> I don't think that's a
Michael Foord wrote:
> On 03/08/2010 09:28, M.-A. Lemburg wrote:
>> P.J. Eby wrote:
>>
>>> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
>>>
If that's the case, then it would be better to come up with an
idea of how to make access to that meta-data available in a less
I/O
On 03/08/2010 09:28, M.-A. Lemburg wrote:
P.J. Eby wrote:
At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
If that's the case, then it would be better to come up with an
idea of how to make access to that meta-data available in a less
I/O intense way, e.g. by having pip or other packa
P.J. Eby wrote:
> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
>> If that's the case, then it would be better to come up with an
>> idea of how to make access to that meta-data available in a less
>> I/O intense way, e.g. by having pip or other package managers update
>> a central SQLite databa
Éric Araujo wrote:
>> What you might want to do is add new type fields to PEP 345,
>> making it easier to identify and list packages that work as
>> plugins for applications, e.g.
>>
>> Type: Plugin for MyCoolApp
>>
>> The MyCoolApp could then use the Type-field to identify all
>> installed plugins
> What you might want to do is add new type fields to PEP 345,
> making it easier to identify and list packages that work as
> plugins for applications, e.g.
>
> Type: Plugin for MyCoolApp
>
> The MyCoolApp could then use the Type-field to identify all
> installed plugins, get their installation
At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
If that's the case, then it would be better to come up with an
idea of how to make access to that meta-data available in a less
I/O intense way, e.g. by having pip or other package managers update
a central SQLite database cache of the data found o
At 09:03 PM 8/2/2010 +0100, Michael Foord wrote:
Ouch. I really don't want to emulate that system. For installing a
plugin for a single project the recommended technique is:
* Unpack the source. It should provide a setup.py.
* Run:
$ python setup.py bdist_egg
Then you wil
At 05:08 PM 8/2/2010 +0200, Ãric Araujo wrote:
I wonder if functions in pkgutil or importlib could allow one to
iterate over the plugins (i.e. submodules and subpackages of the
namespace package) without actually loading then.
See pkgutil.walk_packages(), available since 2.5.
It has to load
Michael Foord wrote:
> On 02/08/2010 20:36, M.-A. Lemburg wrote:
>> Michael Foord wrote:
>>
>>> On 02/08/2010 13:31, exar...@twistedmatrix.com wrote:
>>>
On 12:21 pm, m...@egenix.com wrote:
> Tarek Ziad� wrote:
>
>> On Mon, Aug 2, 2010 at 3:06 AM, P.J.
On 02/08/2010 20:36, M.-A. Lemburg wrote:
Michael Foord wrote:
On 02/08/2010 13:31, exar...@twistedmatrix.com wrote:
On 12:21 pm, m...@egenix.com wrote:
Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
..
So without specific examples
Michael Foord wrote:
> On 02/08/2010 13:31, exar...@twistedmatrix.com wrote:
>> On 12:21 pm, m...@egenix.com wrote:
>>> Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
..
>
> So without specific examples of why this is a problem, it's hard to
> see why
On Mon, Aug 2, 2010 at 8:48 PM, Michael Foord wrote:
> On 02/08/2010 19:45, Holger Krekel wrote:
[...]
I'd much prefer a one-step process and rather provide a way to not-use
a plugin even if installed. The difference is e.g. with py.test that i
can point users to e.g.
p
On 02/08/2010 19:45, Holger Krekel wrote:
On Mon, Aug 2, 2010 at 8:12 PM, Michael Foord wrote:
On 02/08/2010 19:05, Holger Krekel wrote:
On Mon, Aug 2, 2010 at 6:57 PM, Ian Bickingwrote:
Just to add a general opinion in here:
Having worked with Setuptools' entry points
On Mon, Aug 2, 2010 at 8:12 PM, Michael Foord wrote:
> On 02/08/2010 19:05, Holger Krekel wrote:
>>
>> On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking wrote:
>>
>>>
>>> Just to add a general opinion in here:
>>>
>>> Having worked with Setuptools' entry points, and a little with some Zope
>>> pluginis
On 02/08/2010 19:05, Holger Krekel wrote:
On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking wrote:
Just to add a general opinion in here:
Having worked with Setuptools' entry points, and a little with some Zope
pluginish systems (Products.*, which I don't think anyone liked much, and
some ways Z
On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking wrote:
> Just to add a general opinion in here:
>
> Having worked with Setuptools' entry points, and a little with some Zope
> pluginish systems (Products.*, which I don't think anyone liked much, and
> some ways ZCML is used is pluginish), I'm not very
Just to add a general opinion in here:
Having worked with Setuptools' entry points, and a little with some Zope
pluginish systems (Products.*, which I don't think anyone liked much, and
some ways ZCML is used is pluginish), I'm not very excited about these. The
plugin system that causes the least
At 01:10 PM 8/2/2010 +0200, Tarek Ziadé wrote:
I don't have a specific example in mind, and I must admit that if an
application does the right thing
(provide the right configuration file), this activate feature is not
useful at all. So it seems to be a bad idea.
Well, it's not a *bad* idea as s
At 01:53 PM 8/2/2010 +, exar...@twistedmatrix.com wrote:
On 01:27 pm, m...@egenix.com wrote:
exar...@twistedmatrix.com wrote:
This is also roughly how Twisted's plugin system works. One drawback,
though, is that it means potentially executing a large amount of Python
in order to load plugi
On 03:08 pm, mer...@netwok.org wrote:
Le 02/08/2010 14:31, exar...@twistedmatrix.com a �crit :
On 12:21 pm, m...@egenix.com wrote:
Do we really need to make Python packaging even more complicated by
adding support for application-specific plugin mechanisms ?
Packages can already work as applic
On Aug 2, 2010, at 9:53 AM, exar...@twistedmatrix.com wrote:
> On 01:27 pm, m...@egenix.com wrote:
>> exar...@twistedmatrix.com wrote:
>>> On 12:21 pm, m...@egenix.com wrote:
See Zope for an example of how well this simply mechanism works out in
practice: it simply scans the "Prod
Le 02/08/2010 14:31, exar...@twistedmatrix.com a écrit :
> On 12:21 pm, m...@egenix.com wrote:
>> Do we really need to make Python packaging even more complicated by
>> adding support for application-specific plugin mechanisms ?
>>
>> Packages can already work as application plugins by simply defin
On 01:27 pm, m...@egenix.com wrote:
exar...@twistedmatrix.com wrote:
On 12:21 pm, m...@egenix.com wrote:
See Zope for an example of how well this simply mechanism works out
in
practice: it simply scans the "Products" namespace for sub-packages
and
then loads each sub-package it finds to hav
exar...@twistedmatrix.com wrote:
> On 12:21 pm, m...@egenix.com wrote:
>> Tarek Ziad� wrote:
>>> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
>>> ..
So without specific examples of why this is a problem, it's hard to
see why
a special Python-specific set of configuration fil
On 02/08/2010 13:31, exar...@twistedmatrix.com wrote:
On 12:21 pm, m...@egenix.com wrote:
Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
..
So without specific examples of why this is a problem, it's hard to
see why
a special Python-specific set of configuration files is
On 12:21 pm, m...@egenix.com wrote:
Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby
wrote:
..
So without specific examples of why this is a problem, it's hard to
see why
a special Python-specific set of configuration files is needed to
resolve
it, vs. say, encouraging applicat
Tarek Ziadé wrote:
> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
> ..
>>
>> So without specific examples of why this is a problem, it's hard to see why
>> a special Python-specific set of configuration files is needed to resolve
>> it, vs. say, encouraging application authors to use the availa
> The PLUGINS file can be kept only for the state value, which is not read-only.
It will be for OS packages.
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.o
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
..
>
> So without specific examples of why this is a problem, it's hard to see why
> a special Python-specific set of configuration files is needed to resolve
> it, vs. say, encouraging application authors to use the available
> alternatives for doin
On Sun, Aug 1, 2010 at 10:37 PM, Tarek Ziadé wrote:
> Hello,
>
> Here's a proposal to extend PEP 376 to support a basic plugins feature
> -- you should read PEP 376 before reading this mail
>
> It's basically Phillip's entry points, but with an activation flag,
> and a per-user config file.
>
> =
At 02:03 AM 8/2/2010 +0200, Tarek Ziadé wrote:
but then we would be back to the problem mentioned about entry points:
installing projects can implicitly add a plugin and activate it, and break
existing applications that iterate over entry points without further
configuration. So being able to dis
On 02/08/2010 01:03, Tarek Ziadé wrote:
On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord wrote:
On 02/08/2010 00:46, Tarek Ziadé wrote:
[snip...]
I don't think that unittest would use a distutils2 (or pkgutil) supplied
API
for activation.
But the discovery API you w
On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord wrote:
> On 02/08/2010 00:46, Tarek Ziadé wrote:
>>
>> [snip...]
>>>
>>> I don't think that unittest would use a distutils2 (or pkgutil) supplied
>>> API
>>> for activation.
>>>
>>
>> But the discovery API you will use might just simply filter out
>> d
On 02/08/2010 00:46, Tarek Ziadé wrote:
[snip...]
I don't think that unittest would use a distutils2 (or pkgutil) supplied API
for activation.
But the discovery API you will use might just simply filter out
disabled plugins.
I did consider asking this but thought it was a silly ques
On Mon, Aug 2, 2010 at 1:11 AM, Michael Foord wrote:
> This seems fine; I mean it isn't written directly by humans or intended to
> be read directly by humans I guess. :-)
>
> (Users will specify plugins in the setup metadata and this will be written
> on install by distutils2 - right?.)
Yes, exa
On 01/08/2010 21:37, Tarek Ziadé wrote:
Hello,
Here's a proposal to extend PEP 376 to support a basic plugins feature
-- you should read PEP 376 before reading this mail
It's basically Phillip's entry points, but with an activation flag,
and a per-user config file.
= adding a PLUGINS file =
A
On Sun, Aug 1, 2010 at 11:55 PM, Nick Coghlan wrote:
...
> Is dealing with name conflicts left up to the application?
When an application iterates on the plugins that are supposely built
for it, it will probably expect a single type of object. For instance
unitest2 will want classes that are over
On Mon, Aug 2, 2010 at 6:37 AM, Tarek Ziadé wrote:
> Hello,
>
> Here's a proposal to extend PEP 376 to support a basic plugins feature
> -- you should read PEP 376 before reading this mail
>
> It's basically Phillip's entry points, but with an activation flag,
> and a per-user config file.
>
> = a
Hello,
Here's a proposal to extend PEP 376 to support a basic plugins feature
-- you should read PEP 376 before reading this mail
It's basically Phillip's entry points, but with an activation flag,
and a per-user config file.
= adding a PLUGINS file =
A new file called 'PLUGINS' is added to the
51 matches
Mail list logo
