Re: [Repoze-dev] Import error with repoze.sphinx.autointerface
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Felix Schwarz wrote:
I found two minor issues by using repoze.sphinx.autointerface:
1. Can someone please update the pypi page?
http://pypi.python.org/pypi/repoze.sphinx.autointerface/0.1.2 still says
'.. autoinclude:: yourpackage.interfaces.IFoo' however this did not work for
me and indeed README.txt says
'.. autointerface:: yourpackage.interfaces.IFoo' which works.
I will upload 0.1.3 to PyPI, including the changed README.txt in the
long_description field.
2. I was unable to use autointerface 0.1.2 on Fedora 10 (Python 2.5.2)
because
of this:
File .../repoze/sphinx/autointerface.py, line 87, in _resolve_dotted_name
thing = __import__('.'.join(path), {}, {}, [name])
TypeError: Item in ``from list'' not a string
I found out that 'name' contained a unicode string (like u'IFoo'). I was able
to 'fix' this by changing '[name]' to '[str(name)]'. Maybe this is because I
have some umlauts in my full path name (but of course not in a Python module).
Does this patch work for you?
- --- repoze/sphinx/autointerface.py(revision 3167)
+++ repoze/sphinx/autointerface.py (working copy)
@@ -81,7 +81,7 @@
def _resolve_dotted_name(dotted):
#return EntryPoint.parse('x=%s' % dotted).load(False)
- -tokens = dotted.split('.')
+tokens = [str(x) for x in dotted.split('.')]
path, name = tokens[:-1], tokens[-1]
thing = __import__('.'.join(path), {}, {}, [name])
return getattr(thing, name)
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJbd4Z+gerLs4ltQ4RAqjoAJ9xIN2x4MMEAlfqCJg6wZDgXTpkuwCeNeSV
V5UAIftAieEFzSOLDdSspfQ=
=IV2s
-END PGP SIGNATURE-
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Plans for repoze.what v2
Hello, (Phew, finally I had the time to continue this thread.) On Wednesday January 7, 2009 07:04:20 you wrote: You can achieve that with repoze.what predicates. You can write your own predicate to check for that condition: # process the post edition... Apologies, I had too much to say about this topic to confine it to this reply. http://www.plope.com/control_inversion Since we're talking about repoze.what staying middleware, I'm not sure how to get truly general and truly declarative context-sensitive security without creating something that resembles decsec in some way. This is the reason I personally quickly gave up on trying to create a general-purpose athorization framework for arbitrary WSGI apps: there are very few people who are willing to deal with the control inversion that any maximally general system would impose. :-( That's not to say that aiming lower isn't useful to a huge swath of people: it definitely is! But I'd like repoze.what to be something that *I* could eventually use in a way that feels familiar and right (call me selfish). OK, now I think I understand what you meant, specially after reading your comment to the article above whose title is swappability. Your suggestion sounds sensible to me and I'm willing to make the authorization pattern available through decsec in repoze.what, along with the groups/permissions-based pattern. The use cases where one of the two patterns would be useful depend on the developer's likes, but there are several use cases that come to my mind in which *both* patterns would be useful in the same application. One of them is a CMS whose actions use repoze.what predicates (using the groups/permission pattern), *but* its administration interface provides a friendly interface to customize authorization using the context-sensitive pattern (e.g., the CMS allows people with the edit-page permission to edit any page in the website, but the admin may enforce that the Jobs page could only be edited by people in the HR group). Those documents are rather interesting. ACLs are a good alternative to predicate-based assertions, *and* I think they are not mutually exclusive. The components used in the check aren't really all that important to me. I used ACLs in decsec (and in BFG) because the implementation was straightforward and pretty flexible. But the argument was mostly about being able to service applications that required *context-sensitivity* during security checks in repoze.what, not using ACLs to store the data that will be checked. OK, I'll take it into account. I think that if a given routine is performed based on whether the current user is a known spammer (or if a submitted content is spam), according to an anti- spam service, then that's an authorization pattern. Likewise, I think that if a given routine is performed based on whether we are certain that the current user is human, then that's another authorization pattern. OK, I still don't agree but I don't have enough skin in the game to make any compelling argument against this. And because both authorization patterns are widely used, I think they should be supported out-of-the-box, *although* I wouldn't mind to implement such functionalities in two independent packages, as repoze.what plugins that provide the predicates mentioned above. Making them plugins would fit my brain, sorta. OK, then they won't be in the core. Cheers! -- Gustavo Narea http://gustavonarea.net/. Get rid of unethical constraints! Get freedomware: http://www.getgnulinux.org/ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Import error with repoze.sphinx.autointerface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Felix Schwarz wrote: Tres Seaver schrieb: I found out that 'name' contained a unicode string (like u'IFoo'). I was able to 'fix' this by changing '[name]' to '[str(name)]'. Maybe this is because I have some umlauts in my full path name (but of course not in a Python module). Does this patch work for you? Yes, thanks for fixing this. 0.1.3 now released with the fix, as well as the doc update. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJblc0+gerLs4ltQ4RAkbMAJ4oJU3e0SlQ+oO/m+CMEX1ZWIXRRwCgrNzv 6CTU0rTLQwVGN5smbSMSBzc= =1LQm -END PGP SIGNATURE- ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] custom Request and Response classes in repoze.bfg
hey all, so in building my first repoze.bfg app, it's occurred to me that i'd like to use a custom Request and Response classes, just simple subclasses of the WebOb defaults so that i can set configurable class variables like default_charset. unless i'm missing something in the code, there's currently no support for this. how would folks feel about the following changes: - in repoze.bfg.router, the paster config would be checked for request_class setting, which would be a dotted path to a request class to use. absence of this setting means use the default class, nothing changes. - every place that a response object is currently instantiated, use request.ResponseClass instead of explicitly using the WebOb class. AFAICT, response objects are instantiated in the following repoze.bfg modules: - chameleon_[genshi|text|zpt] - view - wsgi - xslt in the 'view' and 'wsgi' modules, we're already holding the request object when the response is instantiated, so there's very little to change. in all of the other modules, the response is being instantiated in a render_[template|transform]_to_response function. the biggest change, then, would be to have all of the render-to-response methods start requiring request objects as arguments. this could be optional at first, w/ a deprecation warning if it's left out, until such time as we might see fit to force the issue. whaddayareckon? -r ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] custom Request and Response classes in repoze.bfg
2009/1/14 Rob Miller r...@burningman.com: so in building my first repoze.bfg app, it's occurred to me that i'd like to use a custom Request and Response classes, just simple subclasses of the WebOb defaults so that i can set configurable class variables like default_charset. unless i'm missing something in the code, there's currently no support for this. You do have the INewRequest event. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] custom Request and Response classes in repoze.bfg
Malthe Borch wrote: 2009/1/14 Rob Miller r...@burningman.com: so in building my first repoze.bfg app, it's occurred to me that i'd like to use a custom Request and Response classes, just simple subclasses of the WebOb defaults so that i can set configurable class variables like default_charset. unless i'm missing something in the code, there's currently no support for this. You do have the INewRequest event. yeah, i saw that, and that's what i'll use as a workaround. but: a) it's less efficient and smells a little bit bad to me to add an event handler and touch every request instance after it's been created when what i really want to do is add a class variable to the request class b) it doesn't address the response object issue. WebOb provides the ResponseClass attribute on the request object specifically for this purpose, it seems silly not to use it. yes, there's an INewResponse event... see a). put another way, ian bicking specifically recommends that subclasses of Request and Response are a good way to handle certain use cases, and WebOb was designed with that in mind. it seems reasonable to me to support doing so. -r ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] custom Request and Response classes in repoze.bfg
Rob Miller wrote: hey all, so in building my first repoze.bfg app, it's occurred to me that i'd like to use a custom Request and Response classes, just simple subclasses of the WebOb defaults so that i can set configurable class variables like default_charset. unless i'm missing something in the code, there's currently no support for this. how would folks feel about the following changes: - in repoze.bfg.router, the paster config would be checked for request_class setting, which would be a dotted path to a request class to use. absence of this setting means use the default class, nothing changes. I think this is more application configuration than deployment configuration so I think it might be better if an IRequestFactory utility was registered via ZCML to be able to override the request factory used by the Router. I'd be willing to put something like this in there if it didn't cause a noticeable slowdown. - every place that a response object is currently instantiated, use request.ResponseClass instead of explicitly using the WebOb class. AFAICT, response objects are instantiated in the following repoze.bfg modules: - chameleon_[genshi|text|zpt] - view - wsgi - xslt in the 'view' and 'wsgi' modules, we're already holding the request object when the response is instantiated, so there's very little to change. in all of the other modules, the response is being instantiated in a render_[template|transform]_to_response function. Note that you could just write your own render_template_to_response function that used render_template and constructed its own kind of response object with the the result of render_template as the response body. That's effectively all that render_template_to_response does. Such a function could be a single line and you could even give it a shorter name! ;-) the biggest change, then, would be to have all of the render-to-response methods start requiring request objects as arguments. this could be optional at first, w/ a deprecation warning if it's left out, until such time as we might see fit to force the issue. I'd also be willing to make a IResponseFactory utility that chameleon_*, view, wsgi, and xslt used to find what kind of response object to get as long as it didn't slow things down much. It would accept no arguments and always return the same kind of response object. I *think* having a global IRequestFactory utility would give you what you wanted; although it wouldn't be able to use request.ResponseClass, as long as what request.ResponseClass means doesn't differ from request-to-request, you would be able to differ the response class for a particular application. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] custom Request and Response classes in repoze.bfg
Chris McDonough wrote: Rob Miller wrote: hey all, so in building my first repoze.bfg app, it's occurred to me that i'd like to use a custom Request and Response classes, just simple subclasses of the WebOb defaults so that i can set configurable class variables like default_charset. unless i'm missing something in the code, there's currently no support for this. how would folks feel about the following changes: - in repoze.bfg.router, the paster config would be checked for request_class setting, which would be a dotted path to a request class to use. absence of this setting means use the default class, nothing changes. I think this is more application configuration than deployment configuration so I think it might be better if an IRequestFactory utility was registered via ZCML to be able to override the request factory used by the Router. I'd be willing to put something like this in there if it didn't cause a noticeable slowdown. yes, that occurred to me as well. i'd be fine w/ a utility. - every place that a response object is currently instantiated, use request.ResponseClass instead of explicitly using the WebOb class. AFAICT, response objects are instantiated in the following repoze.bfg modules: - chameleon_[genshi|text|zpt] - view - wsgi - xslt in the 'view' and 'wsgi' modules, we're already holding the request object when the response is instantiated, so there's very little to change. in all of the other modules, the response is being instantiated in a render_[template|transform]_to_response function. Note that you could just write your own render_template_to_response function that used render_template and constructed its own kind of response object with the the result of render_template as the response body. That's effectively all that render_template_to_response does. Such a function could be a single line and you could even give it a shorter name! ;-) yes, that's easy enough, although it seems quite reasonable to me to use the pattern that WebOb intended for this in the bfg core. the biggest change, then, would be to have all of the render-to-response methods start requiring request objects as arguments. this could be optional at first, w/ a deprecation warning if it's left out, until such time as we might see fit to force the issue. I'd also be willing to make a IResponseFactory utility that chameleon_*, view, wsgi, and xslt used to find what kind of response object to get as long as it didn't slow things down much. It would accept no arguments and always return the same kind of response object. I *think* having a global IRequestFactory utility would give you what you wanted; although it wouldn't be able to use request.ResponseClass, as long as what request.ResponseClass means doesn't differ from request-to-request, you would be able to differ the response class for a particular application. i'm not really following you here. i'm -1 on the idea of an IResponseFactory utility. i think having the ResponseClass available on the request objects meets the need here; the hook is already in WebOb, why not just use it? if anything, i'd rather see an ICurrentRequest utility, which always returned the request object for the current request... or some other way to always get at the request object, regardless of whether or not it's been explicitly passed in. if request.ResponseClass is always used when instantiating a response object, then there's no need to support any other pluggability; the request object serves the need just fine w/o requiring another utility. -r ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] repoze.what configuration issues
Hello guys, I'm trying to add
repoze.who.plugins.basicauth import BasicAuthPlugin
my my base repoze.what config (using TG2)
I followed the instructions here
http://www.turbogears.org/2.0/docs/main/Auth/Customization.html#customizing-authentication-settings
and I found several error as well as things not working as expected.
bugs in the docs
- the sample code is wrong, as BaseAuthPlugin isn't an authenticator.
- setting it as a form_identifies other than having a wrong name add
nothing to the log output of repoze.what
I currently added the following to my app_cfg.py file
base_config.sa_auth.form_plugin = None
http_auth = BasicAuthPlugin('my cool site')
base_config.sa_auth.form_identifies = [('http_auth', http_auth)]
but it just doesn't works
any pointers are appreciated
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [Repoze-checkins] r3174 - repoze.bfg/trunk/repoze/bfg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris McDonough wrote: Author: Chris McDonough chr...@agendaless.com Date: Wed Jan 14 22:16:18 2009 New Revision: 3174 Log: Fix interfaces. Modified: repoze.bfg/trunk/repoze/bfg/interfaces.py Modified: repoze.bfg/trunk/repoze/bfg/interfaces.py == --- repoze.bfg/trunk/repoze/bfg/interfaces.py (original) +++ repoze.bfg/trunk/repoze/bfg/interfaces.py Wed Jan 14 22:16:18 2009 @@ -30,7 +30,7 @@ class IRequestFactory(Interface): A utility which generates a request factory -def __call__(self): +def __call__(environ): Return a request factory (e.g. a callable that accepts an environ and returns an object implementing IRequest, e.g. ``webob.Request``) Doesn't IRequestFactory take an environ and give you back a request? Or is this the HammerFactoryFactory you were joking about on Tuesday? If it is a factory-factory, then why does it need access to the environ? @@ -55,7 +55,7 @@ class IResponseFactory(Interface): A utility which generates a response factory -def __call__(self): +def __call__(*arg, **kw): Return a response factory (e.g. a callable that returns an object implementing IResponse, e.g. ``webob.Response``; it should accept all the arguments that the webob.Response class Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJbqtq+gerLs4ltQ4RAuCqAJ494DnrrenD4olZwRrv8hjc7SlpswCgkHYA b5jhBbWAm7N7Nu/zY0r1Gcg= =S6JV -END PGP SIGNATURE- ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
