Re: [Repoze-dev] [Pyramid-checkins] Broken: Pylons/pyramid#1123 (master - ba0593a)
> On 05 Nov 2014, at 17:55, Tres Seaver wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/05/2014 10:44 AM, Wichert Akkerman wrote: >> >>> On 05 Nov 2014, at 15:57, Tres Seaver >>> wrote: Unicode literals are a no-no for 3.2-compatibility: >> >> How important is 3.2 compatibility? > > We don't ordinarily drop a supported Python version a non-major release. So we can consider dropping 3.2 for Pyramid 1.6? Dropping that would make straddling easier, which sounds worth it to me. > As a dependency for pyramid, if translationstring drops 3.2 > compatiblity, we would need to pin it for "release" branches to versions > which preserved it. Note that the classifiers for translationstring 1.2 > still claim support back to 2.4: > > https://pypi.python.org/pypi/translationstring/1.2 > > although testing versions < 2.6 with tox is no longer feasible. I’ve updated that for the 1.3 release. I’ve also setup travis to automatically run tests on Python 2.6-2.7 and 3.2-3.4. I don’t know if anyone uses the tox configuration, so I’ve left that in place. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org https://lists.repoze.org/mailman/listinfo/repoze-dev
Re: [Repoze-dev] [Pyramid-checkins] Broken: Pylons/pyramid#1123 (master - ba0593a)
> On 05 Nov 2014, at 15:57, Tres Seaver wrote: > Unicode literals are a no-no for 3.2-compatibility: How important is 3.2 compatibility? Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org https://lists.repoze.org/mailman/listinfo/repoze-dev
Re: [Repoze-dev] Jenkins instance (re?) setup
On 03/26/2012 03:46 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I got http://jenkins.repoze.org/ populated over the weekend with all the projects I'm currently supporting (those on GitHub that I can do the maintenance on). There are a number of repos I didn't add, because they are entirely maintained by others (Malthe, Gustavo). I would be fine with putting them into the rotation if the maintainers will add / debug the tox.ini for their repository. fwiw repoze.filesafe is setup on http://jenkins.simplon.biz/ . Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] translation problem
We are running into an i18n conundrum with deform. Basically what
happens is this:
- we have a sequence item in a colander schema with a title, which
is a TranslationString instance
- deform generates an add-button for the sequence which uses this
title using something similar to _('Add ${title}', mapping={...})
When the add button is rendered its label is translated, but the
sequence item title is not translated. I can see two ways of fixing
this:
1. translationstring detects translatable items in its mapping, and
if it finds any it translates those before replacing them
2. deform (and others who do similar things) must manually translate
mapping items
I'm not sure what the best option is. The second option may not be
viable since I'm not sure the request or translate function is available
at the places where you would need it. The first option adds extra
complexity to translationstring, which isn't very attractive either. I
suspect that is still the better option though.
Opinions?
Wichert.
--
Wichert AkkermanIt is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] repoze.depinj behaviour
I am using repoze.depinj in a small project to help replace a backend
database with a dummy version. I was puzzled for quite some time by my
code sometimes getting my test dummy and sometimes getting the real
database. I finally tracked this down to something unexpected in
repoze.depinj: every call to lookup() removes an inserted dummy. Since
my code calls the backend at several places, I ended up having to do
multiple inject() calls in my test. My functional test base class now
looks like this:
def setUp(self):
from repoze.depinj import inject
from customer.portal.run import main
from customer.portal.backend import get_backend
from infrae.testbrowser.browser import Browser
self.backend = DummyBackend()
def dummy_get_backend(request):
return self.backend
# Every lookup() removes an injection, so inject many times
# to make sure multiple get_backend() calls are covered
for i in range(50):
inject(dummy_get_backend, get_backend)
self.app = main({})
self.browser = Browser(self.app)
this works, but is not very pleasant. I could not find any hint in the
repoze.depinj documentation that lookup() is supposed to remove an
override. Is that really the intended behaviour?
Wichert.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg logging configuration through the INI file under mod_wsgi
On 2011-4-4 19:19, Alex Marandon wrote: Hi, Has anyone had any success configuring logging through the main INI file with bfg under mod_wsgi? I keep getting 'No handlers could be found for logger "myapp.mymodule"' messages in apache log file. http://pypi.python.org/pypi/collective.recipe.modwsgi does that for you. If you are not using buildout you will need to add the necessary code to your own wsgi wrapper script. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Migration to Github
On 3/22/11 14:01 , Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2011 09:54 AM, Wichert Akkerman wrote: On 2/22/11 15:40 , Tres Seaver wrote: We have chosen to leave "dormant" projects in SVN for the indefinite future.. Please let us know if there is an existing 'repoze.*' project which you think needs to be migrated: repoze.filesafe is still actively maintained and used, so it should probably be added to the list. Now moved to github: https://github.com/repoze/repoze.filesafe Is there still a way for me to commit to it now? Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon and attribute escape
On 3/7/11 12:09 , Malthe Borch wrote: On 7 March 2011 12:07, Wichert Akkerman wrote: That is the opposite of what I want: I would like invalid markup to be rejected, and I want it to be completely impossible to generate invalid markup. I see. Perhaps there could be a validator sitting in front of the compiler which (as the default) warns of invalid markup. The correct behavior in my view is to accept any markup, but ideally warn (using ``logging.warn``) about it. For input possibly. I consider invalid markup as possible output to be a bug in the template engine. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon and attribute escape
On 3/7/11 12:06 , Malthe Borch wrote: On 7 March 2011 11:59, Wichert Akkerman wrote: Is there a mode to make it impossible to accept or generate invalid markup? For some of us that is very important. That's what this changeset does. It allows you to use invalid markup to the extent possible. For instance, you can use HTML markup: That is the opposite of what I want: I would like invalid markup to be rejected, and I want it to be completely impossible to generate invalid markup. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon and attribute escape
On 3/7/11 11:48 , Malthe Borch wrote: Just wanted to follow up on some issues with attribute escaping that were asked on the channel. I believe I have now adressed these concerns: https://github.com/malthe/chameleon/commit/800306a7433250120e039773ef013702dbaec3fc In particular, you can now use invalid markup such as: It's not valid, but it's also not the business of the template engine to change the markup. Is there a mode to make it impossible to accept or generate invalid markup? For some of us that is very important. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] chameleon zpt: structure or not?
On 3/1/11 12:00 , Chris Withers wrote: Hi All, I hope this is the right list, if not, what's the right list for Chameleon questions? Anyway, the following: ...doesn't appear to quote the html in the "pager" variable. This is different from normal zpt, why the change? It should quote, unless pager has a __html__ method which outputs raw html. See webhelpers.literal for a handy wrapper class for that trick. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Migration to Github
On 2/22/11 15:40 , Tres Seaver wrote: We have chosen to leave "dormant" projects in SVN for the indefinite future.. Please let us know if there is an existing 'repoze.*' project which you think needs to be migrated: repoze.filesafe is still actively maintained and used, so it should probably be added to the list. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] catalog oddness
On 1/14/11 15:04 , Chris Rossi wrote: On Fri, Jan 14, 2011 at 5:20 AM, Wichert Akkerman mailto:wich...@wiggy.net>> wrote: This may already be different in the trunk of repoze.catalog, but I just stumbled over this: when you do a catalog search and ask it to order by an empty index you get an empty result set. I was expecting the result to be an unordered result for that situation. Is this expected behaviour? Hi Wichert, I haven't observed this behavior, but it seems like an undefined case, to me. I'm not sure what I would expect it to do in such a situation. Supposing you have a set of documents you want sorted by an index and the index contains only a subset of those documents? It seems to me the case is undefined--I would have a tendency to raise an exception, personally. I was expecting a missing index value to be treated as None (or NULL in SQL terms) and the related items to appear either first or last. Raising an exception is undesirable: there are valid situations where an object might have a None value for an indexed attribute and that should not lead to exceptions when doing catalog queries. I think in the interest of a well defined determinism I would suggest that if you are using an index to sort, you should make sure that the discriminator for that index be able to return some value for any document. This way even if logically, to you, the document doesn't really have a value for that index, you can at least be deterministic about how it will be sorted. The object did have a value, but it was None which the indexed apparently ignores. The fact that it was always None was a bug in my code that has been fixed now - it should be either None or a date (it was a publication-date field). Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] catalog oddness
This may already be different in the trunk of repoze.catalog, but I just stumbled over this: when you do a catalog search and ask it to order by an empty index you get an empty result set. I was expecting the result to be an unordered result for that situation. Is this expected behaviour? Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] venusian scanning test code
On 2010-12-28 20:34, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/28/2010 01:39 PM, Wichert Akkerman wrote: >> On 2010-12-28 19:16, Chris McDonough wrote: >>> On Tue, 2010-12-28 at 15:36 +0100, Wichert Akkerman wrote: >>>> I recently refactored a package to move all test infrastructure out of >>>> tests/ to testing.py. This has one unfortunate side effect: on installs >>>> without test dependencies my app will now no longer start since the >>>> venusian scan aborts on test imports in testing.py. Is there a way block >>>> venusian from scanning testing.py? >>> >>> I'm afraid not. But I'm not sure why it worked under tests/ but not >>> under testing.py, as Venusian scans everything? >> >> That turned out to due to some other test refactoring I was doing at the >> same time. It did surprise me to see that venusian was scanning tests; >> somehow that feels undesirable. For reference this is the code that was >> showing this problem: >> >> from wsgi_intercept import zope_testbrowser >> >> class TestBrowser(zope_testbrowser.WSGI_Browser): >> """A test browser which does not check robots.txt.""" >> def __init__(self, *args, **kwargs): >> zope_testbrowser.WSGI_Browser.__init__(self, *args, **kwargs) >> self.mech_browser.set_handle_robots(False) >> >> >> since wsgi_intercept is only a test dependency this caused an >> ImportError. As a workaround I hade to rewrite the code to look like this: >> >> def TestBrowser(): >> from wsgi_intercept import zope_testbrowser >> class TestBrowser(zope_testbrowser.WSGI_Browser): >> """A test browser which does not check robots.txt.""" >> def __init__(self, *args, **kwargs): >> zope_testbrowser.WSGI_Browser.__init__(self, *args, **kwargs) >> self.mech_browser.set_handle_robots(False) >> return TestBrowser() >> >> this works, but it isn't very pretty. > > I actually argue that moving imports out of module scope in testcase > modules is best practice: I agree, but in this case TestBrowser is not something that is tested but a utility to help writing tests. It is similar to DummyRequest, DummyModel, etc. That is why I moved it out to testing.py as well. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] venusian scanning test code
On 2010-12-28 19:16, Chris McDonough wrote: > On Tue, 2010-12-28 at 15:36 +0100, Wichert Akkerman wrote: >> I recently refactored a package to move all test infrastructure out of >> tests/ to testing.py. This has one unfortunate side effect: on installs >> without test dependencies my app will now no longer start since the >> venusian scan aborts on test imports in testing.py. Is there a way block >> venusian from scanning testing.py? > > I'm afraid not. But I'm not sure why it worked under tests/ but not > under testing.py, as Venusian scans everything? That turned out to due to some other test refactoring I was doing at the same time. It did surprise me to see that venusian was scanning tests; somehow that feels undesirable. For reference this is the code that was showing this problem: from wsgi_intercept import zope_testbrowser class TestBrowser(zope_testbrowser.WSGI_Browser): """A test browser which does not check robots.txt.""" def __init__(self, *args, **kwargs): zope_testbrowser.WSGI_Browser.__init__(self, *args, **kwargs) self.mech_browser.set_handle_robots(False) since wsgi_intercept is only a test dependency this caused an ImportError. As a workaround I hade to rewrite the code to look like this: def TestBrowser(): from wsgi_intercept import zope_testbrowser class TestBrowser(zope_testbrowser.WSGI_Browser): """A test browser which does not check robots.txt.""" def __init__(self, *args, **kwargs): zope_testbrowser.WSGI_Browser.__init__(self, *args, **kwargs) self.mech_browser.set_handle_robots(False) return TestBrowser() this works, but it isn't very pretty. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] venusian scanning test code
I recently refactored a package to move all test infrastructure out of tests/ to testing.py. This has one unfortunate side effect: on installs without test dependencies my app will now no longer start since the venusian scan aborts on test imports in testing.py. Is there a way block venusian from scanning testing.py? Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Improving renderer setup for views
On 2010-11-3 15:56, Wichert Akkerman wrote:
> I spent some time today trying to figure out why my views where unable
> to find a renderer even though it was registered. It turns out that I
> was calling config.scan() before doing config.add_renderer(). The
> resulting behaviour is a bit misleading: when rendering a view
> RendererHelper.renderer() will raise a ValueError indicating that no
> renderer factory was registered, even though a queryUtility would
> happily return the right factory. I see two ways to improve this:
>
> 1. update RendererHelper.__init__() to check if the result of
> queryUtility(IRendererFactory, name=renderer_type) is None, and if
> so raise an exception. Something like raise ProgrammingError("Trying
> to use a renderer %s which is not (yet) registered") would have
> helped me track this down a lot faster.
FWIW: I was going to implemented this, but noticed that this was already
implemented in Pyramid in changeset
f5fa3f9e2a754ce199386e3f20735cd2dfbbc3fc.
Wichert.
--
Wichert AkkermanIt is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] entry points vs ZCA registrations
On 11/14/10 05:32 , Shane Hathaway wrote: > On 11/12/2010 03:17 PM, Iain Duncan wrote: >> Reading some of the diaolgue on the pylons/bfg merger has me curious >> about the following, wondering if any experts care to share opinions and >> war stories: >> >> - what is the best use case for extending through entry points? >> - why/when would you use entry points and entires in an ini file vs >> registering modules/plugins as zca entries? >> - pros and cons of each approach? > > With ZCA, you can register components temporarily for a test. You can > create a short-lived component registry. You can create multiple > registries for different parts of the application. You can store > registries in a database. Whatever makes sense. > > With entry points, can you do any of that? Entry points seem far more > limiting. Please correct me if I am wrong. Entry points work without you having to configure and python, zcml, etc. code, which makes them a better fit for some tasks. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.catalog clear
On 11/8/10 16:09 , Chris Rossi wrote: > The document_map, while sometimes stored on the catalog, is not known > to the catalog. If you want to clear it, you need to do so explicitly. > This is because r.catalog makes no assumptions about how you retrieve > a document given a docid. The DocumentMap implementation is provided to > fit a common case, but is still up to the app to manage. right. It would be nice if DocumentMap supported a clear() method though. > Depending on what you're trying to do, though, a more satisfying > algorithm might be to use the document_map to find previously indexed > objects and reindex them. We already have that as a separate reindex_catalog command :) Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.catalog clear
On 11/8/10 16:04 , Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/08/2010 09:07 AM, Wichert Akkerman wrote: >> I have some code (from Chris) which rebuilds a repoze.catalog instance. >> It uses a very simple algorithm: >> >> catalog.clear() >> for each obj in root: >>index object >>if object is folderish: >>process al its children >> >> unfortunately there is one problem with this code: any stale items in >> catalog.document_map are not cleared, so there is still cruft remaining >> after rebuilding the catalog. Can that be considered to be a bug? > > Seems like a bug to me. A bug in my app though: looks like Chris implemented a CachingCatalog class which adds catalog.document_map. Without an API to clear a DocumentMap instance I can't clear it though. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] repoze.catalog clear
I have some code (from Chris) which rebuilds a repoze.catalog instance. It uses a very simple algorithm: catalog.clear() for each obj in root: index object if object is folderish: process al its children unfortunately there is one problem with this code: any stale items in catalog.document_map are not cleared, so there is still cruft remaining after rebuilding the catalog. Can that be considered to be a bug? Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] DummyRequest breaks GET/POST API
Since the issue tracker on bfg.repoze.org is still broken I'm posting this here. I ran into a little problem today: I was adding some tests for a function which uses request.POST.getall(), but it turns out that repoze.bfg.testing.DummyRequest uses a plain dict for POST instead of a WebOb multidict, so .getall() is not available. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Improving renderer setup for views
I spent some time today trying to figure out why my views where unable
to find a renderer even though it was registered. It turns out that I
was calling config.scan() before doing config.add_renderer(). The
resulting behaviour is a bit misleading: when rendering a view
RendererHelper.renderer() will raise a ValueError indicating that no
renderer factory was registered, even though a queryUtility would
happily return the right factory. I see two ways to improve this:
1. update RendererHelper.__init__() to check if the result of
queryUtility(IRendererFactory, name=renderer_type) is None, and if
so raise an exception. Something like raise ProgrammingError("Trying
to use a renderer %s which is not (yet) registered") would have
helped me track this down a lot faster.
2. update RendererHelper.renderer() to try the queryUtility again if
self.factory is None, which prevents the need for registering
renderers before setting up the views.
Wichert.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] set_default_permission not working?
On 10/26/10 09:42 , Wichert Akkerman wrote:
> I tried to use config.set_default_permission with repoze.bfg 1.3b1, but
> it appears to do very little. My code looks like this:
>
> config.set_default_permission("authenticated")
> config.scan()
> config.add_route("shop+category+article+detail",
> "/shop/:category/detail/:id",
> factory=factories.ArticleFactory)
> config.add_route(...)
>
> When I run the app with BFG_DEBUG_AUTHORIZATION=1 no permissions are
> hooked up to the views:
>
> 2010-10-26 09:38:19,943 debug_authorization of url
> http://localhost:5000/shop/top/detail/2323 (view name u'' against
> context): Allowed
> (no permission registered)
I figured out why: the bfg_view decorator passes a default permission of
None when it calls config.add_view, but config.add_view tests for a
special _marker value to see if it needs to use the default permission.
If there a special reason add_view has to use a marker instead of None?
Wichert.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] set_default_permission not working?
I tried to use config.set_default_permission with repoze.bfg 1.3b1, but
it appears to do very little. My code looks like this:
config.set_default_permission("authenticated")
config.scan()
config.add_route("shop+category+article+detail",
"/shop/:category/detail/:id",
factory=factories.ArticleFactory)
config.add_route(...)
When I run the app with BFG_DEBUG_AUTHORIZATION=1 no permissions are
hooked up to the views:
2010-10-26 09:38:19,943 debug_authorization of url
http://localhost:5000/shop/top/detail/2323 (view name u'' against
context ): Allowed
(no permission registered)
Wichert.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon vs. jQuery templating, round one
On 2010-10-12 19:40, Paul Everitt wrote:
>
> Hi all. Before this floats out of my brain, I thought I'd write it down and
> see what people think.
>
> In the past few months I've done a bit of client-side templating in jQuery,
> first using John Resig's microtemplating:
>
>http://ejohn.org/blog/javascript-micro-templating/
>
> ...as well as the just-announced-as-core templating:
>
>
> http://blog.jquery.com/2010/10/04/new-official-jquery-plugins-provide-templating-data-linking-and-globalization/
>
> I used these in KARL which uses Chameleon 1.1.1. All was happy.
>
> I tried both today on a new project which uses Chameleon 1.2.13. Chameleon
> didn't like the syntax, which in one case looks like this:
>
><% some expression %>
>
> and in another:
>
>${somevar}
>
> In the first case, Chameleon refuses to parse the zpt because Expat tries to
> interpret<% as a startTag. In the second case...needless to say, it is
> ironic that we have overlap in syntax. I then tried wrapping a CDATA around
> the block, but Chameleon happily plowed into the CDATA looking for stuff to
> evaluate.
You can locally disable ${..} interpolation in chameleon:
...
I use that all the time to prevent problems with $variable names in
javascript.
Wichert.
--
Wichert AkkermanIt is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] good error traceback middlewear?
On 2010-10-7 16:32, Fernando Correa Neto wrote: > I remember seeing pylons or tg2 displaying very nice tracebacks. I'm > not sure it it's actually a middleware but worth looking though. They use WebError. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue155] Support encoding of cookies on repoze.who cookie plugin
On 2010-7-13 17:37, Nuno Teixeira wrote: > > -def __init__(self, cookie_name, cookie_path='/'): > +def __init__(self, cookie_name, cookie_path='/', charset=None): Can we standardise on using 'encoding' as parameter name instead of 'charset' ? I think we use encoding everywhere else as well. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zodbconn connection handling
On 6/25/10 20:18 , Charlie Clark wrote: > Am 25.06.2010, 20:03 Uhr, schrieb Wichert Akkerman: > >> I am using repoze.zodbconn in a BFG application but I suspect it is not >> working as it should be: as soon as multiple requests come in at the >> same time I get a lot of locking errors and broken results: >> LockError: Couldn't lock >> '/Users/wichert/Work/code/buildout/blackbox/var/Data.fs.lock' > > Hiya Wiggy, > > I've been getting similar issues when I run checks with ab on a site. I > thought it was down to Snow Leopard's notoriously sluggish file system. Is > this similar to your environment? Yes, but I do not think that is the culprit. Chris convinced me that my reasoning was wrong: PersistentApplicationFinder does open the database only once and stores the database in a class instance variable, so the problem is elsewhere. The current thinking is that this is a race with multiple threads trying to open the database for the first time. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zodbconn connection handling
On 6/25/10 20:03 , Wichert Akkerman wrote: > The way I've setup repoze.zodbconn is > > from repoze.zodbconn.finder import PersistentApplicationFinder > from myproject import appmaker > finder = PersistentApplicationFinder(settings["zodb.url"], appmaker) > def get_root(request): > return finder(request.environ) > return get_root [.. snip ..] > What I think should be done is to open the ZODB connection on app > startup and only appmaker(conn.root90) per request. ZODB should then > care of per-thread connection management itself. I see no way to > accomplish that using the code in repoze.zodbconn, so I am wondering if > I missed something critical or if this is indeed a bug in repoze.zodbconn. I've rewritten my code to look like this: from repoze.zodbconn.uri import db_from_uri db=db_from_uri(settings["zodb.url"]) conn=db.open() def get_root(request): return appmaker(conn.root()) return get_root and removed the EnvironmentDeleterMiddleware from the WSGI chain since I no longer put anything in environ. So far it looks like this works, but I'ld like some confirmation from the gurus here. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] repoze.zodbconn connection handling
I am using repoze.zodbconn in a BFG application but I suspect it is not working as it should be: as soon as multiple requests come in at the same time I get a lot of locking errors and broken results: LockError: Couldn't lock '/Users/wichert/Work/code/buildout/blackbox/var/Data.fs.lock' The way I've setup repoze.zodbconn is from repoze.zodbconn.finder import PersistentApplicationFinder from myproject import appmaker finder = PersistentApplicationFinder(settings["zodb.url"], appmaker) def get_root(request): return finder(request.environ) return get_root the get_root method then serves as the root factory for BFG. What I think is happening is that get_root is called for every request. get_root then calls the PersistentApplicationFinder which tries to open a new ZODB connection, which fails if another thread already has an open connection to the same FileStorage. What I think should be done is to open the ZODB connection on app startup and only appmaker(conn.root90) per request. ZODB should then care of per-thread connection management itself. I see no way to accomplish that using the code in repoze.zodbconn, so I am wondering if I missed something critical or if this is indeed a bug in repoze.zodbconn. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] cogbin is back - please add/update keyword turbogears2 in your setup.py and upload to pypi.
On 6/25/10 16:50 , Lukasz Szybalski wrote: >>> django-lazysignup 0.1.2 >>> django-lockdown 0.1.1 >>> django-paranoid-sessions 0.2.0 >>> grokproject 2.0.1 >>> So unfortunately the >>> Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware >>> gives out even more projects that are not related. >> >> If you see packages with incorrect Trove classifiers please contact their >> maintainer and ask them to correct it. Please don't make their fault our >> problem :) > > Just so I'm clear here. Assuming the "trove classifiers" are correct > for the packages above; that means they should work with > "turbogears2"? The package above do not have the WSGI middleware trover classifier because you did a completely different search. All proper WSGI middleware packages should work fine with turbogears. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] cogbin is back - please add/update keyword turbogears2 in your setup.py and upload to pypi.
On 6/24/10 16:51 , Lukasz Szybalski wrote: > Unfortunately if you look at : > > http://pypi.python.org/pypi?%3Aaction=search&term=Middleware&submit=search That is not the right query: it does not filter by trove classifier but searches for a fairly common word. Try this query instead: http://pypi.python.org/pypi?:action=browse&show=all&c=319&c=326&c=506&c=509 > You see other packages that are not repoze, like: > > django-lazysignup 0.1.2 > django-lockdown 0.1.1 > django-paranoid-sessions 0.2.0 > grokproject 2.0.1 > So unfortunately the > Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware > gives out even more projects that are not related. If you see packages with incorrect Trove classifiers please contact their maintainer and ask them to correct it. Please don't make their fault our problem :) Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] static views and @@
On 6/24/10 09:28 , Chris Withers wrote:
> Hi All,
>
> I've registered a static view with:
>
> config.add_static_view('static','mypackage:templates/static')
>
> Which, if I read the docs, means I should be able to build urls such as:
>
> /@@static/some.css
I can't remember seeing any use of @@ in BFG docs. Where did you see that?
> If I change is to:
>
> /static/some.css
>
> ...it works.
>
> What am I doing wrong?
Thinking too much of Zope and using @@ would be my guess.
Wichert.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Paste 1.7.4, security fix for XSS hole
On 6/24/10 09:07 , Ian Bicking wrote: > I believe the changes to 1.7.4 are limited and upgrading will have a low > impact. Is there a changelog somewhere? The paste website still lists 1.7.3 as the last release and the pypi page has no changelog information. If I look at http://bitbucket.org/ianb/paste/src/30425672adf7/.hgtags there are two 1.7.4 tags? Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] cogbin is back - please add/update keyword turbogears2 in your setup.py and upload to pypi.
On 6/23/10 17:27 , Chris McDonough wrote: > I think this is maybe a little backwards. > > Many, many repoze things will work in turbogears 2 (almost all repoze > middleware such as repoze.who and repoze.tm2 as well as libraries such > as deform, colander, venusian, etc). But they'll also work fine in any > other WSGI framework too, so there's nothing particularly special about > them working in Turbogears 2, and adding a "turbogears2" keyword might > make people think that they *don't* work in other WSGI frameworks. > > Is there something else I can do? Use some more neutral keyword? Are we already using the "Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware" classifier? Everything in that category should work fine with turbogears and the classifier is nicely generic. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.folder API weirdness
On 6/17/10 16:36 , Charlie Clark wrote: > Am 17.06.2010, 16:08 Uhr, schrieb Tim Hoffman: > >> I would be concerned if you tried to __setitem__ a new page to replace >> the >> existing folder of the same name >> thus blowing away a whole heap of subfolders and documents in the >> process. > > Agreed but "mv" will let you do this but there are things in the shell > that shouldn't necessarily be emulated... mv will not do that: mv will put the file inside the folder. Filesystems are different here in that they have clear file and folder concepts. In the ZODB you do not have those concepts. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.folder API weirdness
On 6/17/10 14:53 , Chris McDonough wrote: > On Thu, 2010-06-17 at 11:28 +0200, Wichert Akkerman wrote: >> I noticed something odd in repoze.folder: __setitem__ does not allow you >> to replace an existing item. This is a result from __setitem__ being an >> alias for add(). Is that a deliberate design decision? If not I'ld like >> to change it to allow replacing items. > > The folder API isn't meant to exactly mirror the dictionary API, so I > don't consider this odd. Most CMS-ish UI operations that call for > adding a new item also call for aborting if an item by that name already > exists, so we default to that behavior. > > But it probably doesn't matter much. As long as the deletion sends (or > doesn't) the proper ObjectRemoved, etc events, I'd be sort of +0 on > being able to replace an existing item. I think this would imply > changing .add rather than changing __setitem__. Please read the > docstrings for .add and .remove before changing much; we need to retain > the ability to add and remove an item with and without sending events. > If we change things so doing an addition replaces, and if someone adds a > new item that already exists, .add should call .remove with the > send_events argument the same value as what was passed to .add. My suggestion would be to make __setitem__ always do remove and add with events. If someone needs more control they can explicitly call add and remove directly. Allowing add() to replace items feels counterintuitive to me. To put this in code my proposal would be: def __setitem__(self, key, item): """Set a child item, optionally replacing an existing item with the same key. This will always fire object events. If you want to block events use add() and remove() directly. """ if key in self: self.remove(key) self.add(key, item) Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] repoze.folder API weirdness
I noticed something odd in repoze.folder: __setitem__ does not allow you to replace an existing item. This is a result from __setitem__ being an alias for add(). Is that a deliberate design decision? If not I'ld like to change it to allow replacing items. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Best practice approach for protection against cross-site-scripting and cross-site request forgery
On 6/4/10 09:28 , Andreas Jung wrote:
recommended approach for
> protecting a BFG app against XSS and CSRF?
Below is the code I use. The basic idea is that my users have a 'secret'
attribute which is reset every time they login. This value is included
in all forms in a hidden csrf_token field. I then used a subclass of the
standard formish Form class which validates the CSRF token. This works
well and is easy to use. The only slightly tricky bit is that you need
to make sure you don't reset the secret if someone submits two logins
forms in parallel, so make sure you only reset the secret if the user
was anonymous before.
Wichert.
def currentUser(request):
"""Return the currently :obj:`capos.model.account.Account` , or
`None` if the current user is anonymous."""
policy = request.registry.getUtility(IAuthenticationPolicy)
userid = policy.authenticated_userid(request)
if not userid:
return None
return meta.Session.query(Account).get(userid)
def checkCSRF(request):
"""Check if the request has a valid CSRF token."""
user=currentUser(request)
if user is None:
return True
token=request.POST.getall("csrf_token")
if [user.secret]==token:
return True
log.warning("Invalid CSRF token from account %s (id=%d): %r",
user.login, user.id, token)
return False
class CSRFForm(formish.Form):
"""Base class for forms which verifies CSRF tokens. Tokens have
to be passed in as a HTTP POST parameter called `csrf_token`.
GET requests are not allowed to prevent tokens from appearing in
proxy or webserver logfiles."""
def validate(self, request, failure_callable=None,
success_callable=None,
skip_read_only_defaults=False, check_form_name=True):
if not checkCSRF(request):
raise Forbidden("Invalid CSRF token")
return super(CSRFForm, self).validate(request, failure_callable,
success_callable,
skip_read_only_defaults,
check_form_name)
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [chameleon bug] bugtracker url wrong in docs.
On 6/3/10 11:27 , Malthe Borch wrote: > We should try and consolidate all these different bug trackers. It's a > mess. Too bad we don't have the proper top-level name for this. I > don't know that I agree with the name "chameleon-template-engine". Hm, wasn't it you who created that tracker? Odd! Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] problems running chameleon tests
On 6/3/10 11:37 , Chris Withers wrote: > Malthe Borch wrote: >> Really that's odd; > > How do you run the tests? Same as all (non-Zope) python packages: python setup.py test > Hmm, it occurs to me that even if the [test] extra_requires was there, I > don't know how to feed that into: > > python setup.py develop Why should that install test requirements? That is not what develop is for. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [chameleon bug] bugtracker url wrong in docs.
On 2010-6-2 23:48, Chris Withers wrote: > First hit for me was: > > https://launchpad.net/chameleon.genshi > > Is that related? A fork? Something else? chameleon.genshi was merged into Chameleon 1.2.0. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [chameleon bug] bugtracker url wrong in docs.
On 2010-6-2 23:02, Chris Withers wrote: > Chris Withers wrote: >> On the off chance you meant a bug tracker, I'll post both of these >> bugs there. > > And the docs for the bug tracker are wrong... > > https://code.launchpad.net/chameleon is a ruby-based blogging project... A 5 second search on launchpad would have pointed you to https://bugs.launchpad.net/chameleon-template-engine . I'll fix the link in svn. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] url dispatch, args, matchdicts
On 2010-6-2 21:48, Iain Duncan wrote: > Hmm, what about adding another optional param to route tags? something > like use_global_views, but as a flag for the passing in named args > automatically? I would think a lot of people coming to bfg from other > frameworks and using it as a micro-framework would really like that. Or > am I the only one? ;-) I suspect you are :). I came from Pylons and have not missed that feature in BFG. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [chameleon bug]
On 2010-6-2 20:38, Chris Withers wrote: > What tracker should I put this in? Please see http://chameleon.repoze.org/docs/latest/ which documents this. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] BFG, override configurator settings after Config construction
On 2010-4-24 19:49, Chris McDonough wrote: > Even better, just leave the authentication policy registrations out of ZCML > altogether and always pass the authentication and authorization policies to > the > Configurator constructor instead: > > config = Configurator(authentication_policy=..., authorization_policy=...) FWIW several times it would have been useful for me if there was an API to set the auth policies after creating the configurator instead of having to specify them at construction time. A common scenerio is that I have a function which does the application setup which calls various other functions to configure specific parts such as i18n/l18n, URLs, etc. by calling them with the Configurator instance as parameter. At the moment the API does not allow that for auth policies. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] wrapped views for routes?
On 4/21/10 11:23 , Chris McDonough wrote: > The spelling: > > > > Is syntactic candy that can also be spelled like this: > > > > > So you can probably do this: > > > > wrapper="some-other-view"/> > name="some-other-view"/> > > I haven't tried this, but I'm pretty sure it will work. It does if you do the same thing in python. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] GAE or other 'cloud' choices for bfg apps?
On 4/15/10 14:57 , Charlie Clark wrote: > Am 15.04.2010, 01:48 Uhr, schrieb Iain Duncan: > >> Also curious about the economics of cloud deployment vs renting servers, >> input welcome. > > That's very much apples and spaceships. Utility services (cloud is such a > deliberately "nebulous" (sic) and misleading team) can be unbeatable on > price for calculation which is why genome analysis is often done with > them. Isn 't it incredibly hard to predict costs for cloud services? Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Chameleon 1.1 and z3c.pt problems
On 4/9/10 20:30 , Hanno Schlichting wrote: > > > icon > > > text > > > > You can easily save 2 * len(items) function calls here, by using one > more temporary variable. I haven't figured out who or what code should > do something to avoid this yet :) You can't do that. For all you know iterating over items might have a side-effect which influences the result of view.useIcons. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] BFG PyCon BOF Summary
Thanks for the writeup! On 2/23/10 14:14 , Chris McDonough wrote: > Documentation > - > > - People would like to see a tutorial which hand-held people through > the process of moving from a imperative configuration to a > declarative configuration, and perhaps vice versa. Interesting - I would have expected the other direction to be more popular. Do you know why people seem to prefer declarative? > DVCS > > > There was some general agitation to move from SVN to a DVCS. I think > there's general consensus that this is a good idea. My reservations > are these: > > - Any choice about which DVCS we make will be "wrong": it's still > unclear which DVCS systems will "win" and which ones will "lose". > If the DVCS we choose turns out to be the "wrong" one, we'll need to > switch VC systems again in a couple of years. > > - I don't know how we'd handle contributor agreements. > > Even with these outstanding concerns and questions, I think we should > probably indeed move to a DVCS sometime soon -- maybe within the next > six months or so. When we do, Agendaless will play the role of tyrant > and choose which DVCS that will be and how it gets set up, and how > contributor agreements are handled. There's no way I can stop you > from expressing an opinion about how this process should work and the > concrete choice of DVCS, but personally I'm unlikely to respond; > please don't be disappointed if there isn't a resulting negotiation. From a personal perspective I'm likely to only contribute in the form of emailing patches if you move away from svn. Luckily I only contribute small things, so feel free to ignore me. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] System Error; Transaction closed
On 2010-2-20 02:39, Darryl Cousins wrote: > Hi, > > I'm frequently coming across a problem with the transaction. A typical > traceback is included below. > > Relevant section of paste.ini: > > [pipeline:main] > pipeline = > responselogger > browserid > deliverance > beaker > egg:repoze.tm2#tm > who > myapp > > I don't call session.commit() anywhere in my code. And on refresh the > error disappears (usually the first refresh, sometimes on second or > third refresh). > > Has anyone else come across this problem and if so what was the > solution or source of the problem? In my experience this happens if you had a SQL error happen earlier which closed the transaction. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] BFG book available from Amazon.com (better shipping rates?)
On 2010-2-7 04:27, Chris McDonough wrote: > A number of folks in Europe indicated that the shipping rates for the > "repoze.bfg Web Application Framework" book from Createspace to Europe were > prohibitive. The book is now available from Amazon.com. I don't really know > what the Amazon shipping rates to Europe *are*, but hopefully they're better: From memory Amazon.com is still expensive with shipping. If the book lands on something like amazon.co.uk or amazon.de things should improve. Of course people could also just order it at their local bookstore :) Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plone use with plone versions > 3.1?
On 2010-1-17 07:33, Martin Aspeli wrote: > Hanno Schlichting wrote: > >> repoze.zope2 and .plone have been written largely by Agendaless for >> the KARL project. That project has gone through another iteration and >> nowadays uses repoze.bfg without any Plone instead. While there are >> some individual users of the repoze.plone approach, there's currently >> no driving party behind it anymore. > > Specifically, we should point out that: > >- repoze.zope2 is a re-implementation of ZPublisher that is more WSGI > compatible. There are probably at least a dozen people using this > "seriously". It's clearly not mainstream, but it also has some > interested stakeholders. > >- repoze.plone and the zopelib package were ways to get everything to > build properly before Zope and plone were eggified. With Plone 4 / Zope > 2.12, they are both completely unnecessarily. With Plone 3.2+ and Zope > 2.10, repoze.plone is unnecessary, and zopelib can be emulated by > installing a regular Zope installation using plone.recipe.zope2install. There is something to consider: I suspect more things are started to require the new publisher events from Zope2, either directly or via one of the backport packages for Zope 2.10. I'm not sure if repoze.zope2 supports those. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] configurator add_route usage
The current bfg docs do not seem to explain add_route very well. The URL dispatch section briefly mentions its existance, but does not show anything beyond a very trivial usage. Trying to use it it seems that you have to pass a Python callable directly as view parameter, instead of a reference to a callable as the docstring for add_route seems to imply. Note that I am interpreting 'reference to' as a dotted path, since otherwise you would not be using a reference but the actual thing. This is a bit awkward since it means you have to import all your view code from run.py. Would it be possible to support dotted paths in add_route (and thus add_view as well)? Relatedly it seems there is a flaw in the add_view example in the views chapter. It has this example: config.add_view(name='my_view', request_method='POST', for_=MyModel, permission='read') which is missing the view parameter. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [Repoze-checkins] r7852 - in repoze.bfg/branches/wichert-paster: . repoze/bfg repoze/bfg/paster_templates/alchemy repoze/bfg/paster_templates/alchemy/+package+ repoze/bfg/paster_templ
On 2010-1-7 06:11, Chris McDonough wrote: > OK, I took a look... Besides the paster thing, everything looks ok to > me. Thanks for the work. > > Currently there are import errors that would prevent either the alchemy > or the routesalchemy template from actually working. Please run pyflakes > on a rendered version of both templates and commit fixes if you want > this to make it in. Certainly. Since git-svn is being nothing except problematic for me and I have little internet access here I probably will not be able to do that this week. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [Repoze-checkins] r7852 - in repoze.bfg/branches/wichert-paster: . repoze/bfg repoze/bfg/paster_templates/alchemy repoze/bfg/paster_templates/alchemy/+package+ repoze/bfg/paster_templ
On 2010-1-6 21:51, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Wichert Akkerman wrote: > >>> I wouldn't go there, myself: among other things, you lose the ability >>> to do coordination with repoze.retry (e.g., on Postgres' equivalent to a >>> ConflictError). >> >> I'm not sure why you would loose that. I've never used repoze.retry, so >> perhaps I'm missing something. Could you expand a bit on that? > > repoze.retry does what the Zope publisher does on ConflictErrors, but > can be configured to catch other exceptions besides ConflictError: > PGSQL has an optimistic concurrency mode which raises a simliar > exception. You can also tweak the number of retries. Ok. > Wiring tm2 into the app makes it impossible to configure retry in the > "correct" place via PasteDeploy: you would have to hardwire *it* into > the app as well (retry needs to be between tm2 and the app). That is what I would do indeed. Personally I consider endware to be part of the application instead of its configuration, so I want that to be in python. I gather that you and Chris feel otherwise, which is fine as well. There is a small downside / awkwardness you have to deal with if you use a paste deploy pipeline: you have to manually specify the config part of your application if you use setup-app or any other paster command. In other words you need to do: paster setup-app config.ini#app otherwise your setup method is called with the pipeline configuration (since that is 'main') instead of the app configuration. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [Repoze-checkins] r7852 - in repoze.bfg/branches/wichert-paster: . repoze/bfg repoze/bfg/paster_templates/alchemy repoze/bfg/paster_templates/alchemy/+package+ repoze/bfg/paster_templ
On 2010-1-6 21:43, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Wichert Akkerman wrote: > >> Modified: repoze.bfg/branches/wichert-paster/CHANGES.txt >> == >> --- repoze.bfg/branches/wichert-paster/CHANGES.txt (original) >> +++ repoze.bfg/branches/wichert-paster/CHANGES.txt Wed Jan 6 12:06:06 2010 >> @@ -69,6 +69,18 @@ >> - Add a (minimal) tutorial dealing with use of ``repoze.catalog`` in a >> ``repoze.bfg`` application. >> >> +- Modify PasteScript templates to perform database schema setup and >> + creation of initial content in the setup-app command instead of >> + on every app start. > > Seems sensible. > >> +- Modify PasteScript templates to support the PasteScript setup-app command. >> + >> +- Modify PasteScript templates to move the repoze.tm2 endware setup to >> python >> + code. > > I wouldn't go there, myself: among other things, you lose the ability > to do coordination with repoze.retry (e.g., on Postgres' equivalent to a > ConflictError). I'm not sure why you would loose that. I've never used repoze.retry, so perhaps I'm missing something. Could you expand a bit on that? Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] repoze.bfg template changes
I'm about (or have done by the time you get this - I'm writing this offline) to commit a bfg branch which reworks the paster templates a bit. Most of the changes are inspired by the Pylons templates, and all of them felt like improvements to me. If you approve of the changes I can take a look at updating the code for the tutorials and accompanying documentation as well. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] authorization debug problem
I use a custom authorization problem, but noticed that when I enable BFG_DEBUG_AUTHORIZATION it always reports "no authorization policy in use". I am guessing this happens because the authorization policy is registered after the routes are setup, so the queryUtility calls in authdebug_view happen too early. If I move them inside the _authdebug_view method things work properly. I'm not sure what the right fix is: reordering the configuration, or moving those queryUtility calls. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] zope.autointerface: using the autointerface crashes sphinx
On 10/22/09 21:44 , Jean Daniel wrote: > Hello, > > I can't document python interfaces with the autointerface directive > for Sphinx and Zope interface. I use the simplest setup in a virtual > env with the latest autointerface and sphinx eggs. > > The document I try to compile is the basic template generated by > sphinx-quickstart and the class I try to document is the class IFoo > from the zope Interface doc on Pypi. > > I have also used the repoze.sphinx.autointerface from trunk in 0.3dev, > it is possible that I am missing something obvious... What was missing is that I apparently never merged the autointerface branch to trunk. I've done that now and I'll put a 0.3 release on pypi which should work correctly for you. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Problem of showing Formish form in repoze.bfg
On 10/24/09 10:11 , Malthe Borch wrote: > 2009/10/24 Tres Seaver: >> No, it works fine for values wich aren't markup: if you want a variable >> containing markup to be rendered without escaping, you need the >> 'structure' directive in TAL: the shortcut always escapes markup. > > Alternatively, wrap your ``addform`` value as a literal (``from > webhelpers.html import literal``, not sure which package this comes > from). From webhelpers :) Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.sphinx.autoinclude changes
On 2009-8-19 23:48, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Wichert Akkerman wrote: >> I did a little work on repoze.sphinx.autoinclude to update it for the >> API changes in Sphinx 0.6. There is one noticable change compared to >> current trunk: there is a new 'interface' directive you can use for >> interfaces. It works exactly like the standard 'class' directive. >> >> None of the old test code worked with the new code and was not very >> easily reusable, so I've removed it for now. That means the new code is >> fully untested. Unfortunately I will not be able to do any more work on >> it in the next 3 weeks since I'll be off on vacation on a bit end of >> this week. I'm hoping someone else will be able to add some tests in the >> meantime. If not my work-schedule after the vacation is frightfully >> empty at the moment so I should have time to do it then. > > Sorry for the delay in replying: I kept meaning to get back to you, but > my own schedule got in the way. I'm happy with seeing any maintenance > on r.s.a at all, but likely won't get back to work on it anytime in the > foreseeable future. Would you be agreeable to making a release (or me making the release if you give me pypi access) based on my changes, even without new tests? That will allow people to start using autoinclude while we/I find the time to restore the missing tests. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] repoze.sphinx.autoinclude changes
I did a little work on repoze.sphinx.autoinclude to update it for the API changes in Sphinx 0.6. There is one noticable change compared to current trunk: there is a new 'interface' directive you can use for interfaces. It works exactly like the standard 'class' directive. None of the old test code worked with the new code and was not very easily reusable, so I've removed it for now. That means the new code is fully untested. Unfortunately I will not be able to do any more work on it in the next 3 weeks since I'll be off on vacation on a bit end of this week. I'm hoping someone else will be able to add some tests in the meantime. If not my work-schedule after the vacation is frightfully empty at the moment so I should have time to do it then. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] repoze.sphinx.autoinclude 0.2 does not work
I'm afraid repoze.sphinx.autoinclude 0.2 still has several problems. It
needs a versioned dependency on docutils to make sure it does not get
the old docutils that comes with Zope2, which breaks the Directive
import. After I fix that manually a sphinx-build run aborts with this
error for me:
Exception occurred:
File
"/Users/wichert/Library/eggs/repoze.sphinx.autointerface-0.2-py2.4.egg/repoze/sphinx/autointerface.py",
line 86, in _resolve_dotted_name
thing = __import__('.'.join(path), {}, {}, [name])
ValueError: Empty module name
Wichert.
--
Wichert AkkermanIt is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] chameleon.genshi with expressions inside non-XHTML attributes
On 7/11/09 8:32 PM, Alberto Valverde wrote:
> Hello,
>
> I'm trying to use chameleon.genshi (trunk) to generate a WMS
> GetCapabilities document but expressions inside non-xhtml attributes are
> not evaluated, eg:
>
>
>
> renders "${service_url}" instead of the value of 'service_url'
>
> The same template renders correctly with genshi 0.5 so I'm using it as a
> workaround for XML templates but I'd like to drop this dependency if
> feasible. If this is really a bug (I suspect it isn't since language.py
> appears to ignore dynamic non-xhtml attributes by design) I could send
> some tests showing the error.
This looks like a bug. Genshi syntax is pretty explicit about this
having to work; it is an integral part of dynamic XIncludes for example.
Wichert.
--
Wichert AkkermanIt is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Getting Started with repoze.bfg - installing repoze.shootout, lxml errors
On 7/8/09 2:07 PM, david bain wrote: > I stuck at installing repoze.shootout. > using python2.4, virtualenv --no-site-packages, and ubuntu with > build-essentials. Can you try installing libxml2-dev as well? Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg vs buildout
On 6/24/09 3:22 PM, Chris Withers wrote: > Chris Rossi wrote: >> On Wed, Jun 24, 2009 at 9:16 AM, Chris Withers> <mailto:ch...@simplistix.co.uk>> wrote: >> >> >> Also, how do you wire running tests, particularly running them with >> nose, into this? >> >> bin/nosetests path/to/src > > ...having added nosetests as a dependent egg, right? > > How/where do you encapsulate options to nosetests such that they don't > have to be continuously re-typed? setup.cfg Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [TurboGears] Re: repoze.what-pylons host no longer up
Hi Gustavo, is there a special reason the repoze.what docs can not be hosted on docs.repoze.org, next to all the other repoze documentation? Wichert. On 6/11/09 6:23 PM, Gustavo Narea wrote: > Hi, everyone. > > Jorge's right, my personal server, which hosts code.gustavonarea.net and > what.repoze.org, is down. > > Unfortunately, it's not something I can fix. My ISP was hacked recently, but > I've been told it should come back up in a few hours. > > Otherwise I'll start serving those sites from my home network later today, > although its upstream rate sucks (but it's better than nothing). > > Cheers! > >- Gustavo. > > > > Jorge said: >> On Wed, Jun 10, 2009 at 11:08 PM, Jesse Howarth wrote: >>> The host for repoze.what-pylons has been down for 3 days now. PyPi >>> has it listed at http://code.gustavonarea.net/repoze.what-pylons/ and >>> when "python setup.py develop" is run for either 2.0 or 2.1 it stalls >>> and eventually fails. >> This is correct, aparently there is something wrong with gustavo's server >> ;( ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] security changes...
Previously Chris McDonough wrote:
> On 5/26/09 4:07 AM, Chris McDonough wrote:
> > On 5/26/09 3:52 AM, Wichert Akkerman wrote:
> >> Previously Chris McDonough wrote:
> >>>def remember(self, principal, token):
> >>>""" Return a set of headers suitable for 'remembering' the
> >>>principal on subsequent requests """
> >>>
> >>>def forget():
> >>>""" Return a set of headers suitable for 'forgetting' the
> >>>current user on subsequent requests"""
> >> It would be nice if there was also a handy utility function to apply
> >> those headers to a response. I suspect that code is often repeated now.
>
> Oops, missed this one...
>
> This might mean the difference between:
>
> from repoze.bfg.security import logout
>
> def someview(context, request):
> response = render_template_to_response('some.pt')
> logout(response)
> return response
>
> vs.
>
> from repoze.bfg.security import forget
>
> def someview(context, request):
> response = render_template_to_response('some.pt')
> headers = forget()
> response.headerlist.extend(headers)
> return response
The first variant feels better. I can not see a use case where you would
ever want to manipulate the headers returned by logout()/remember()
before adding them to the response, so folding the response header
updating into the function itself makes sense. Saves one often
duplicated line of code.
> But since BFG doesn't have a global response object like Pylons does, it's
> not
> possible to do:
>
> def someview(context, request):
> logout()
> return render_template_to_response('some.pt')
>
> .. if that's what you mean.
Luckily that is not what I meant :)
Wichert.
--
Wichert Akkerman It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] security changes...
Previously Chris McDonough wrote:
> On 5/26/09 3:52 AM, Wichert Akkerman wrote:
> > Previously Chris McDonough wrote:
> >> def remember(self, principal, token):
> >> """ Return a set of headers suitable for 'remembering' the
> >> principal on subsequent requests """
> >>
> >> def forget():
> >> """ Return a set of headers suitable for 'forgetting' the
> >> current user on subsequent requests"""
> >
> > It would be nice if there was also a handy utility function to apply
> > those headers to a response. I suspect that code is often repeated now.
> >
> >> class IAuthorizationPolicy(Interface):
> >> """ An adapter on context """
> >> def permits(self, principals, permission):
> >> """ Return True if any of the principals is allowed the
> >> permission in the current context, else return False """
> >>
> >> def principals_allowed_by_permission(self, permission):
> >> """ Return a set of principal identifiers allowed by the
> >> permission """
> >
> > There are situations where principals_allowed_by_permission may not be
> > possible, or at least very expensive. In LDAP/AD environments for
> > example getting a list of all principles is often not doable. This
> > should be reflected in the API somehow. Perhaps allow for
> > principals_allowed_by_permission to return a value indicating it is not
> > willing to support this?
>
> I don't think principals_allowed_by_permission does what you think it does.
> Or
> at least what I meant it to do. In a traversal-based app, it's essentially a
> walk of the object ("model") graph from the root along some path to a
> particular
> context collecting identifiers for users who "have" that permission.
Ok. I see the difference here: you use the proper definition of
principals, why I mentally had expandede groups to turn it into a list
of users. That requires access to some storage, while just generating a
list of principals does not. I agree that using proper principals here
makes sense, and makes my point obsolete.
> > I wonder if we should also set the exceptions that can be thrown by
> > those routines. Depending on the implementation that can be DB-API
> > exceptions, LDAP exceptions, or anything else which would mean that
> > people using this API will end up have to use a bare try/except.
>
> Can you provide an example situation where some system wasn't up to this task?
A common one are transient errors, such as a connection failure during a
database restart. LDAP can be difficult since it will raise an exception
if a search would return more than a fixed limit of results (often set
to 500). AD environments, especially with forests, may not allow you to
query the list of principles at all (which makes sense, there can be
many tens of thousands of principles).
Wichert.
--
Wichert Akkerman It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] security changes...
Previously Chris McDonough wrote: > def remember(self, principal, token): > """ Return a set of headers suitable for 'remembering' the > principal on subsequent requests """ > > def forget(): > """ Return a set of headers suitable for 'forgetting' the > current user on subsequent requests""" It would be nice if there was also a handy utility function to apply those headers to a response. I suspect that code is often repeated now. > class IAuthorizationPolicy(Interface): > """ An adapter on context """ > def permits(self, principals, permission): > """ Return True if any of the principals is allowed the > permission in the current context, else return False """ > > def principals_allowed_by_permission(self, permission): > """ Return a set of principal identifiers allowed by the permission > """ There are situations where principals_allowed_by_permission may not be possible, or at least very expensive. In LDAP/AD environments for example getting a list of all principles is often not doable. This should be reflected in the API somehow. Perhaps allow for principals_allowed_by_permission to return a value indicating it is not willing to support this? The same holds for the version in ISecurityPolicy. I wonder if we should also set the exceptions that can be thrown by those routines. Depending on the implementation that can be DB-API exceptions, LDAP exceptions, or anything else which would mean that people using this API will end up have to use a bare try/except. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
Previously Martin Aspeli wrote: > Shane Hathaway wrote: > > Fernando Correa Neto wrote: > >> Adding new template engines to BFG require you to know python while in > >> GROK, it'd require you to grok grok first (which in would then > >> introduce the developer to ZCA) which is definitely a Zope3 thing. > > > > You hit on a point that I consider important. One of the interesting > > things about ZCML (and hence BFG) is it's easy for any Python developer > > to write their own directives. ZCML doesn't violate DRY, as I once > > thought it did, because if you find yourself writing repetitive > > directives, you can just create a custom directive in Python instead. > > > > Unfortunately, Grok obscures that simplicity. It seems much harder to > > add new kinds of decorators than it is to add new kinds of ZCML directives. > > You're sure about that? I find it easier to write a new grokker (whether > for a decorator or a more generic class grokker that looks for a base > class) than a new ZCML directive (and I've done plenty of both). Approaching this from another point of view: debugging a grokker that does not behave as you expect is much harder than debugging a zcml statement or a python imperative statement. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] templating engine speed comparisions
Previously Chris Withers wrote: > Malthe Borch wrote: > > We use a custom parser based on ``xml.parsers.sax`` –– it's in > > ``chameleon.core.etree``. > > > >> How do you guys to speed profiling? Would be interested to see how the > >> speed > >> compares with and without lxml and across various templating engines... > > > > The ``lxml`` library is only used in the compilation process; it's not > > used at all while rendering. > > Interesting, but the bit of my question is still unanswered: > > Are there any speed-comparison suites for templating engines out there? > Would be really interesting to compare them all... chameleon has a benchmarker somewhere in its sources. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] removing the lxml dependency from bfg
Previously Malthe Borch wrote: > 2009/4/27 Reed O'Brien : > > +0 I think it is OK to have a default one. Think "hello world". > > Devil's advocate here, but: > > >>> print "Hello world" > > You kind of don't need a templating language; in particular, you might > want to serve up binary files only, combined with JSON input/output. > We actually do that in ``repoze.filecat``. That works, but any first user of repoze.bfg is bound to want to try a template, and not bundling any default templating languages will make that first introduction to bfg more complicated. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.who plugins
Previously Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Christoph Zwerschke wrote: > > Hello, a question about the repoze.who plugin concept: > > > > I'm just writing a plugin for authentication against an XML-RPC service, > > implementing the authenticator and metadata provider interfaces . > > > > Inside the authenticate() method, I make a call to the XML-RPC service > > to check if the user exists and has entered the right password. That > > same call already returns all the metadata about the user that I need. > > > > What's the best way to store that information so that it can be reused > > later in the add_metadata() method? I want to avoid making another > > costly call to the remote service. Simply stuff the information > > somewhere into the environ or identity dict? > > > > The same applies when you have to check a remote database with the sql > > plugin. Currently, every successful authentication makes two queries, > > one to check whether the users exist and one to get their data. Wouldn't > > it be better to handle both tasks with one query? The api with the > > different plugin types is nice, but it also causes such redundant calls. > > Or do I overlook something? > > IAuthenticator plugins are free to scribble on the 'identity' mapping > passed to authenticate, which should mean that you can avoid registering > a metadata plugin at all. You could also add information to the > 'environ' directly, if need be. If you use auth_tkt you will probably want a metadata plugin which only does something if the metadata hasn't been set yet. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue60] repoze.who auth_tkt is broken when using string userid containing spaces
Wichert Akkerman added the comment: Ideally a userid should be considered to be a bytestring. This is especially true in Active Directory environments where the userid really is a binary string (the ObjectGUID attribute). __ Repoze Bugs <http://bugs.repoze.org/issue60> __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.who-based form protection middleware
Previously Malthe Borch wrote: > Such parameters are typically found in cookies; for example, a session > id or a login credentials token. Is that safe? Isn't there a risk of that csrf cookies persisting longer than the auth session? Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bug: easy_install repoze.who-friendlyform
Previously Tres Seaver wrote: > More packaging issues (note that I haven't actually used the package, > I'm just looking at how it installs): > > - - Why is there a MANIFEST.in in the package? Setuptools already > includes data files from an SVN checkout automatically. Because you may work from an export, of a fork stored in git via git-svn, or any of many other reasons. I also consider adding a MANIFEST.in good form. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Add logout url to RedirectingFormPlugin
I have what I think is a reasonably common use case: on logout I want to redirect the user to a thanks-for-stopping-by page. Currently RedirectingFormPlugin always generates an unauthorized exception on logout, which triggers the challenger to show the login page again. I implemented that on a new repoze.who branch in the form of a new option for the plugin: logout_page_url. If this parameter is passed in a redirect to that URL is generated. Unless there are any objections I will merge this later today. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.who and script_name
Previously Tres Seaver wrote: > There *is* no status code corresponding to "log out." I don't think > logging out can be done cleanly by middleware, fraknly: I think there > should be a "forgetCredentials" API which the app calls when it knows > that the user has requested a logout. Just like there should be a 'rememberCredentials' API the app can call. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
Previously Martin Aspeli wrote: > Wichert Akkerman wrote: > > Previously Martin Aspeli wrote: > >> If you want to pull in, say, plone.supermodel (a "pure Zope 3" package > >> that should be re-usable and may be useful to BFG if it ever wants to > >> serialise Zope 3 schema interfaces to/from an XML representation) well, > >> it uses zope:* ZCML directives. Are you going to fork plone.supermodel? > > > > I would be very tempted at least. Or decide to not use supermodel. > > Which would mean that the BFG-intersecting parts of the repoze stack > would be a fork or re-implementation of all Zope stuff that was > interesting to it. I don't see that. That is just my personal opinion and might not hold for anyone else here. Zope packages have a tendency to pull in half the zope world and introduce a lot of zcml and security that you almost never want in a non-zope environment. Unfortunately there appears to be little will in zope-dev to actively change that. That's a shame, since it it drastically reducing the chance of zope technology being accepted and used by others. If reimplementing something is easy to do (which is generally true considering we all have Zope's source) and allows you to drop all that extra baggage that - why not? Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
Previously Martin Aspeli wrote: > If you want to pull in, say, plone.supermodel (a "pure Zope 3" package > that should be re-usable and may be useful to BFG if it ever wants to > serialise Zope 3 schema interfaces to/from an XML representation) well, > it uses zope:* ZCML directives. Are you going to fork plone.supermodel? I would be very tempted at least. Or decide to not use supermodel. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
Previously Martin Aspeli wrote: > Chris McDonough wrote: > > > That package is now done... > > > > http://static.repoze.org/zcmldocs > > > > and > > > > http://pypi.python.org/pypi/repoze.zcml/0.1 > > > > I've adjusted the trunk of bfg and the trunk of chameleon.zpt to use ZCML > > declaration implementations from this rather than using the "stock" > > implementations from zope.component. > > Given that Plone also uses chameleon.zpt (via five.pt) this means that, > if I understand correctly, Plone now gains this dependency, and part of > the Plone stack uses what will seem to most people like an arbitrary, > almost-identical-but-not-quite way of configuring components that's > different to what the rest of the stack uses. I'm not sure that is true: people can still use the standard zope zcml directorives instead of the repoze.zcml alternatives and everything will work normally. The only downside is that chameleon.zpt will pull in a few extra packages, but you yourself have argued that that should not bother people. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [ANN] EggFreezer
Previously Alberto Valverde wrote: > I've just recently scratched a long standing itch I had: The need to > "freeze" an EGG distribution, along with all of its requirements, into a > single .py file that can be reinstalled at any time, even with *no* net > access. How does it compare with zc.sourcerelease? From what you describe that does the exact same thing, except it produces a buildout instead of a virtualenv. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [Plone-developers] repoze.bfg
Previously Malthe Borch wrote: > Chris McDonough wrote: > > I've been working on a new web framework named (provisionally) repoze.bfg. > > This looks very interesting; I'd be curious to see if this could be > useful for Vudo. I'd like it very much if Vudo could sit on top of a > more general framework (not just the Zope 3 libraries). > > Early on, the idea was that this could be Grok, but it quickly turned > out that Grok makes too many assumptions for our use. > > I recently pasted a basic Pylons application and it gives you something > that I think would be attractive in a Zope/Vudo/Bfg-based setup: A > canonical directory structure, e.g. > > ./templates > ./routers > ./config templates - page templates controllers - the pylons-version of views. sort-of. config - everything related to the appplication configuration lib - all our utilities models - data models public - static web content Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.bfg
Previously Ian Bicking wrote: > Chris McDonough wrote: > > I've been working on a new web framework named (provisionally) repoze.bfg. > > > > The relevant README is here: > > http://svn.repoze.org/repoze.bfg/trunk/README.txt > > > > It is essentially a "Zope lite". It is Zope-ish in that: > > > > - it uses a lot of Zope libraries and concepts (interfaces, some CA > > constructs, > > ZCML) > > > > - it uses graph-traversal-based URL dispatch. > > I feel like there's some... different perspective on things that would > be useful to understand in this case. I'm not sure exactly how you are > implementing this. Like, Zope (and TG), with getattr? Incidentally, TG > uses Routes with a default route that points to the object publisher, > which is similar to what you suggest doing in a response in this thread. > > Anyway, I feel like there's some useful distinction to be teased out > here, with next-segment URL analysis (like in object publishing) and > whole-URL analysis (with Routes). paste.urlmap being another example of > next-segment. For Zope there are two packages that make it possible to use something similar to routes inside Zope as well: megrok.trails allows you to do routes-style traversal from a content object. z3c.routes (far from usable still) allows the same but goes a bit further in that it allows the publisher to continue with content/graph-based traversal after it has processed a route, making it possible to mix routes and graph-style traversing in any way you want. Which mechanism you use depends highly on the use case. For hierarchical content such as Zope gets from the ZODB content traversing is extremely intuitive and practical. When you deal with applications that are as content-centric routes makes more sense since you are not traversing over content(ish) objects. I've often had a wish to be able to combine the two so you can start with contrnt traversal to get to an object and use a routes-style traverser from there to find the right controller. In more Zopeish terminology I want to use routes to get a parameterized view for the context. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] gzo: pages too wide
I suspect this is a case of wrong-list ? Wichert. Previously Michael Haubenwallner wrote: > Hi, i've compiled a list of docs that are too wide for my FF display at > 1024px and sometimes even too wide for a 1280px display. > > Adding 'overflow: auto;' to '.documentContent pre' in > 'gzo.plonesmashtheme.css' should solve the problem. > > Heres the list: > http://grok.zope.org/documentation/book/ > http://grok.zope.org/documentation/how-to/grok-virtual-hosting-and-nginx > http://grok.zope.org/documentation/tutorial/installing-and-setting-up-grok-under-mod-wsgi/tutorial-all-pages > http://grok.zope.org/documentation/tutorial/installing-and-setting-up-grok-under-mod-wsgi/installing-and-configuring-mod-wsgi > http://grok.zope.org/documentation/tutorial/installing-and-setting-up-grok-under-mod-wsgi/installing-and-configuring-a-grok-site-under > http://grok.zope.org/documentation/how-to/grok-orm-with-storm > > Michael > > -- > http://www.zope.org/Members/d2m > http:/planetzope.org > > ___ > Repoze-dev mailing list > Repoze-dev@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
