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
Floris Bruynooghe wrote:
On Wed, Dec 02, 2009 at 03:43:28PM +0100, Tarek Ziadé wrote:
Ok so, if everyone agrees on those two, I am proposing to add for now :
- Repository-Browse-URL : url to a web-browseable repository (no
distinction whether its the trunk,
a branch etc)
I'm still uneasy
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
Folks,
in setuptools-0.6c11-py2.6.egg/setuptools/package_index.py lines 468-475
if dist is None:
...
return dist.clone(...)
= of course
AttributeError: 'NoneType' object has no attribute 'clone'
return None if dist is None else dist.clone(...)
fixes yolk.
(Does nobody else use yolk ? I like
i've setup private pypi where i can upload some packages that are not
suitable for pypi.python.org.
my package, let's call it myapp, contains
install_requires=['django',] but with that requirement i can't
install it.
--
$ virtualenv
On 12/4/2009 2:43 AM, denis wrote:
Folks,
in setuptools-0.6c11-py2.6.egg/setuptools/package_index.py lines 468-475
if dist is None:
...
return dist.clone(...)
= of course
AttributeError: 'NoneType' object has no attribute 'clone'
Fixed in setuptools trunk -
On Fri, Dec 4, 2009 at 7:04 PM, Sridhar Ratnakumar
sridh...@activestate.com wrote:
On 12/4/2009 2:43 AM, denis wrote:
Folks,
in setuptools-0.6c11-py2.6.egg/setuptools/package_index.py lines 468-475
if dist is None:
...
return dist.clone(...)
= of course
AttributeError: 'NoneType'
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
Hi,
I am currently fixing a bug in Distutils: http://bugs.python.org/issue1923
this bugs makes a Description field like:
Text::
a literal python block::
import this
Transformed into :
Text::
a literal python block::
import this
Which is fine for RFC822 compliancy but
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
17 matches
Mail list logo
