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 rel
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 ea
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 act
On Sat, Dec 5, 2009 at 10:27 AM, Andrew Dalke 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 data_files is that it
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 /Library/Python/2.6/site-packages/Spam_services-0.0.0-py2.6.egg-
On Sat, Dec 5, 2009 at 12:22 AM, Andrew Dalke 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, that's how it works, you c
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_modu
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 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_poi
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 "
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 Managem
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,
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 inst
On Thu, Dec 3, 2009 at 1:06 AM, 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
>
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:
inst
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 consid
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 $AKARA/spa
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 file
18 matches
Mail list logo
