Andrew Dalke a écrit :
On Dec 4, 2009, at 9:18 AM, kiorky wrote:
ZopeComponentArchitecture/Entry points with an assembler like buildout for
the
later won't pollute site-packages
I tried searching for ZopeComponentArchitecture/Entry points but found
nothing that seemed relevant. Did
David Cournapeau a écrit :
Tarek Ziadé wrote:
where package.spam_extension and spam_extension2 are modules Akara
would simply __import__()
Meaning a plugin will be a normal project that gets installed, and
then configured to be used in Akara.
This solution is simpler, but it does not
David Cournapeau wrote:
This solution is simpler, but it does not solve the issue of installing
the plugin outside site-packages. I think it is good practice not to
pollute site-packages with app-specific plugins.
Just use buildout and be done with it ;-)
Chris
--
Simplistix - Content
On Dec 3, 2009, at 8:09 PM, Tarek Ziadé wrote:
What about having an explicit configuration file in Akara for plugins,
where you just add extensions, exactly like mercurial does:
[extensions]
foo = package.spam_extension
bar = spam_extension2
where package.spam_extension and
On Dec 4, 2009, at 9:18 AM, kiorky wrote:
ZopeComponentArchitecture/Entry points with an assembler like buildout for the
later won't pollute site-packages
I tried searching for ZopeComponentArchitecture/Entry points but found
nothing that seemed relevant. Did you mean setuptools entry_points?
On Dec 4, 2009, at 5:29 AM, David Cournapeau wrote:
This solution is simpler, but it does not solve the issue of installing
the plugin outside site-packages. I think it is good practice not to
pollute site-packages with app-specific plugins.
This tangential topic came up recently because of
On Dec 3, 2009, at 7:58 PM, P.J. Eby wrote:
It wouldn't be so much of a change as an addition. You'd just add code like
this, either before or after your existing loop over the extensions directory:
for entry_point in pkg_resources.iter_entry_points('akara'):
extension_module =
On Sat, Dec 5, 2009 at 12:22 AM, Andrew Dalke da...@dalkescientific.com wrote:
[..]
I looked at the installation instructions for mercurial packages listed at
http://mercurial.selenic.com/wiki/UsingExtensions . They all require
hand-editing of the hgrc file. That is not what I want.
Yes,
On Dec 3, 2009, at 4:46 AM, David Cournapeau wrote:
If you think this is insane, you are not alone :)
I think that by hooking into data_files I can be a bit less insane. What's
wrong with this? Other than that it writes
Writing
On Sat, Dec 5, 2009 at 10:27 AM, Andrew Dalke da...@dalkescientific.com wrote:
On Dec 3, 2009, at 4:46 AM, David Cournapeau wrote:
If you think this is insane, you are not alone :)
I think that by hooking into data_files I can be a bit less insane. What's
wrong with this?
The problem of
At 12:34 AM 12/5/2009 +0100, Andrew Dalke wrote:
I had some concerns about them. For one, all of the plugins define
out-word facing web services on our server. If the plugins can be
located in arbitrary locations inside of site-packages, how does the
administrator know which plugins will be
At 01:18 AM 12/5/2009 +0100, Andrew Dalke wrote:
It appears that pkg_resources does some caching, including using
linecache. I can't tell how well it would work if our pluging
packages were updated after the main server was running.
If you need to ensure that you get a fresh list of plugins
On Dec 3, 2009, at 4:46 AM, David Cournapeau wrote:
The way I
would do it is by having akara distutils extensions, which define in
particular a setup function and associated classes.
...
If you think this is insane, you are not alone :)
Wow. That's just crazy, I say - crazy.
I
At 01:06 AM 12/3/2009 +0100, Andrew Dalke wrote:
Hi all,
I'm working with the Akara project. It contains a web server. The
server loads extensions from a special directory (let's say
$AKARA for now). An extension can register handlers for URLs. An
example extension might look like:
On Thu, Dec 3, 2009 at 1:06 AM, Andrew Dalke da...@dalkescientific.com wrote:
Hi all,
I'm working with the Akara project. It contains a web server. The server
loads extensions from a special directory (let's say $AKARA for now). An
extension can register handlers for URLs. An example
Tarek Ziadé wrote:
where package.spam_extension and spam_extension2 are modules Akara
would simply __import__()
Meaning a plugin will be a normal project that gets installed, and
then configured to be used in Akara.
This solution is simpler, but it does not solve the issue of installing
Hi all,
I'm working with the Akara project. It contains a web server. The server
loads extensions from a special directory (let's say $AKARA for now). An
extension can register handlers for URLs. An example extension might look like:
installs to $AKARA/spam_extension.py
(note: only .py files
Andrew Dalke wrote:
Hi all,
I'm working with the Akara project. It contains a web server. The server
loads extensions from a special directory (let's say $AKARA for now). An
extension can register handlers for URLs. An example extension might look
like:
installs to
18 matches
Mail list logo
