Re: [pylons-devel] Help with testing Pyramid app composition done with config.include()

[Michael Merickel]

The request.registry = ... is fine and supported. The alternative is that you 
can just do everything with the threadlocal pushed and then DummyRequest will 
pick up the registry automatically.

with config:
request = DummyRequest()
path = request.route_path(route_name)

Or manually with config.begin(); ...; config.end().

- Michael

> On Dec 3, 2020, at 23:30, Karl O. Pinc  wrote:
> 
> Hi Micheal,
> 
> Thanks very much for the prompt reply.   My reply inline below.
> 
> On Thu, 3 Dec 2020 22:16:15 -0600
> Michael Merickel mailto:mmeri...@gmail.com>> wrote:
> 
>> Have you looked at querying data out of the introspector after
>> config.commit()?
>> 
>> For example, the following will return the route descriptors
>> registered for this name [1]:
>> 
>> config.introspector.get('routes', route_name)
> 
> I did, but didn't get very far.  I probably didn't read the
> narrative docs you link to below and instead got lost in the API
> reference.  *doh*
> 
> Introspection seems the right way to go.  Thanks!
> 
> There can't be much of a down-side to having introspection
> turned on for production, should I decide to work on my
> second problem below, or the default wouldn't be True.
> 
>> You can also make a dummy request and use it to generate routes. For
>> example:
>> 
>> request = DummyRequest()
>> # set request properties like host etc to adjust how the url is generated 
>> request.registry = config.registry
>> path = request.route_path(route_name)
> 
> I thought about this.  But doing "request.registry = config.registry"
> seemed unsupported voodoo, however appealing and easy to do in
> testing code.  If you'd like to comment
> on this I'd be interested but don't feel you have to reply.
> 
>> [1]
>> https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/introspector.html#using-the-introspector
>> 
>> - Michael
>> 
>>> On Dec 3, 2020, at 14:21, Karl O. Pinc  wrote:
>>> 
>>> Hi,
>>> 
>>> I've a Pyramid app that's composed of multiple python distributions
>>> (packages).  I'm writing integration tests for the code that calls
>>> Configurator() and then uses the resulting config to do
>>> config.include() on the various components.
>>> 
>>> The application uses URL dispatch.  Mostly, the config.included()ed
>>> components setup routes to their views.  But routes can also be
>>> overridden by settings, sometimes settings acted upon by the
>>> included components and sometimes settings acted upon by my main
>>> Pyramid app. Route prefixes are added and removed at a couple of
>>> points in the code path.
>>> 
>>> I want a functional test to check that the configuration produced by
>>> my code establishes the expected routes -- that the route names
>>> exist and that when request.route_url() (etc.) are called the
>>> expected URLs result.  I can't find a direct way to do this.
>>> 
>>> I _could_ use WebTest to call my wsgi app, passing it various paths
>>> and poking about inside the result body to try to figure out that
>>> the right view was called.  But this seems clunky and does not
>>> directly tell me that I've got the right route names in existence
>>> and that they produce the right paths.
>>> 
>>> I can't seem to use pyramid.testing.SetUp() to generate a request so
>>> that I can call request.route_path().  SetUp() returns it's own
>>> configuration, but I want to test the configuration produced by my
>>> code.
>>> 
>>> The code I want to test is, roughly:
>>> 
>>>   rp = settings.get('route_prefix')
>>>   with Configurator(settings=settings, route_prefix=rp) as config:
>>>   config.include('this_compoent_always_exists')
>>>   for component in components_to_config():
>>>   config.include(component)
>>>   my_code_that_does_more_route_frobbing(config, settings)
>>>   do_more_initializing(config, settings)
>>>   return config# to main(), which returns config.make_wsgi()
>>> to pyramid
>>> 
>>> 
>>> Any help would be appreciated.  Thanks.
>>> 
>>> 
>>> There is a related issue.  I don't use route patterns that contain
>>> replacement markers.  The route paths are "fixed".  I make a many of
>>> the route paths available to my templates, for navbar
>>> generation ,etc.
>>> 
>>> Presently I'm calling request.route_path(), at runtime when
>>> generating a response, with r

Re: [pylons-devel] Help with testing Pyramid app composition done with config.include()

[Michael Merickel]

Have you looked at querying data out of the introspector after config.commit()?

For example, the following will return the route descriptors registered for 
this name [1]:

config.introspector.get('routes', route_name)

You can also make a dummy request and use it to generate routes. For example:

request = DummyRequest()
# set request properties like host etc to adjust how the url is generated
request.registry = config.registry
path = request.route_path(route_name)

[1] 
https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/introspector.html#using-the-introspector

- Michael

> On Dec 3, 2020, at 14:21, Karl O. Pinc  wrote:
> 
> Hi,
> 
> I've a Pyramid app that's composed of multiple python distributions
> (packages).  I'm writing integration tests for the code that calls
> Configurator() and then uses the resulting config to do
> config.include() on the various components.
> 
> The application uses URL dispatch.  Mostly, the config.included()ed
> components setup routes to their views.  But routes can also be
> overridden by settings, sometimes settings acted upon by the included
> components and sometimes settings acted upon by my main Pyramid app.
> Route prefixes are added and removed at a couple of points in the
> code path.
> 
> I want a functional test to check that the configuration produced by
> my code establishes the expected routes -- that the route names exist
> and that when request.route_url() (etc.) are called the expected URLs
> result.  I can't find a direct way to do this.
> 
> I _could_ use WebTest to call my wsgi app, passing it various paths
> and poking about inside the result body to try to figure out that the
> right view was called.  But this seems clunky and does not directly
> tell me that I've got the right route names in existence and that they
> produce the right paths.
> 
> I can't seem to use pyramid.testing.SetUp() to generate a request so
> that I can call request.route_path().  SetUp() returns it's own
> configuration, but I want to test the configuration produced by my
> code.
> 
> The code I want to test is, roughly:
> 
>rp = settings.get('route_prefix')
>with Configurator(settings=settings, route_prefix=rp) as config:
>config.include('this_compoent_always_exists')
>for component in components_to_config():
>config.include(component)
>my_code_that_does_more_route_frobbing(config, settings)
>do_more_initializing(config, settings)
>return config# to main(), which returns config.make_wsgi() to pyramid
> 
> 
> Any help would be appreciated.  Thanks.
> 
> 
> There is a related issue.  I don't use route patterns that contain
> replacement markers.  The route paths are "fixed".  I make a many of
> the route paths available to my templates, for navbar generation ,etc.
> 
> Presently I'm calling request.route_path(), at runtime when generating
> a response, with route names determined based on whatever
> config.include()ed components happen to be installed.  The results go
> into a data structure made available to my templates.  But this data
> structure is the same for every request.  It would be nice to produce
> the data during configuration and re-use it when requests arrive.
> 
> I seem to have the same problem discovering route paths for my templates
> during configuration that I have when trying to write an integration test
> that discovers the route paths configured go with my route names.  There's
> no way to give a configuration a route name and get a route path.
> (Presumably, such a thing would have to be done after calling
> config.commit().)
> 
> I can file an issue at github if that would help resolve any of these
> questions and keep them from getting lost.
> 
> Regards,
> 
> Karl 
> Free Software:  "You don't pay back, you pay forward."
> -- Robert A. Heinlein
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pylons-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pylons-devel/20201203142116.3bde490d%40slate.karlpinc.com.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-devel/7B412747-C681-435C-94BE-39987E0655BF%40gmail.com.

Re: [pylons-devel] i18n state of affairs

[Michael Merickel]

On Thu, Feb 9, 2017 at 6:02 AM, Hans-Peter Jansen  wrote:

> There's one decision to make as the next step:
>
> Does the involved parties agree to leave the translation procedures
> somewhat
> outside the normal workflow and supply a i18n.sh script, accompanied with a
> default lingua.cfg file, that checks and proposes to install "lingua" and
> "babel", if missing?
>
> "lingua" will be used for extraction, "babel" provides the extraction
> plugins
> for "mako" and "jinja2" templates, that are used by lingua's pot-create
> script.
>
> Does anybody foresee any problems with this approach?
>

I don't see any problem with this. It sounds great. A few requests below
(not requirements, just my picture of what the i18n story would ideally
turn into as we move forward).

1) Update the pyramid documentation to explain what's going on and how
things fit together, including an example i18n.sh or i18n.py.

2) Try to support windows as much as possible and so i18n.py might be worth
considering instead, along with an attempt to explain what is necessary to
get things to work on windows.

3) I'd like things to work for arbitrary projects and not just colander and
deform. It'd be great if they served as best practice examples.

- Michael

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] i18n in deformdemo dysfunctional

[Michael Merickel]

I got the renderer working via the following diff. Unfortunately the
translator is still not invoked which leads me to believe that there is
something wrong with the i18n tags in the chameleon templates, but I don't
know enough about chameleon to dive in there. Hopefully this was helpful
though.

diff --git a/deformdemo/__init__.py b/deformdemo/__init__.py
> index 098046a..6f023f6 100644
> --- a/deformdemo/__init__.py
> +++ b/deformdemo/__init__.py
> @@ -70,7 +70,7 @@ def translator(term):
>  deform_template_dir = resource_filename('deform', 'templates/')
>  zpt_renderer = deform.ZPTRendererFactory(
> -[deform_template_dir], translator=translator)
> +(deform_template_dir,), translator=translator)
>  # the zpt_renderer above is referred to within the demo.ini file by
> dotted name
> @@ -2763,8 +2763,8 @@ def main(global_config, **settings):
>  config.include('pyramid_chameleon')
>  renderer = config.maybe_dotted(renderer)
> -#deform.Form.set_default_renderer(renderer)
> -deform.renderer.configure_zpt_renderer(["deformdemo:custom_widgets"])
> +deform.Form.set_default_renderer(renderer)
> +deform.renderer.configure_zpt_renderer(("deformdemo:custom_widgets",))
>  config.add_static_view('static_deform', 'deform:static')
>  config.add_static_view('static_demo', 'deformdemo:static')


On Wed, Feb 8, 2017 at 4:19 PM, Michael Merickel <mmeri...@gmail.com> wrote:

> I noticed that the renderer is not being used. The
> `deform.Form.set_default_renderer(render)` is commented out. Uncommenting
> it doesn't solve the problem but it's definitely an issue as the
> zpt_renderer isn't actually being used as a result.
>
> On Wed, Feb 8, 2017 at 4:14 PM, Michael Merickel <mmeri...@gmail.com>
> wrote:
>
>> The issue is *usually* that the TranslationString instance hasn't been
>> run through `request.localizer.translate(..)`. Now, why not? I haven't
>> dug in to try and figure that out yet.
>>
>> On Wed, Feb 8, 2017 at 3:55 PM, Hans-Peter Jansen <h...@urpla.net> wrote:
>>
>>> Hi,
>>>
>>> I've used a good part of the day for getting i18n fixed in deformdemo,
>>> but failed so far. :(
>>>
>>> While all debug instrumentation show green lights, the translation
>>> strings aren't picked up for some reason:
>>>
>>> 2017-02-08 22:49:07,717 DEBUG [deformdemo:63][waitress] locale_name from
>>> default_locale_negotiator: de
>>> 2017-02-08 22:49:07,718 DEBUG [deformdemo:2080][waitress] locale_name:
>>> de, request._LOCALE_: de
>>> 2017-02-08 22:49:09,795 DEBUG [deformdemo:63][waitress] locale_name from
>>> default_locale_negotiator: en
>>> 2017-02-08 22:49:09,795 DEBUG [deformdemo:2080][waitress] locale_name:
>>> en, request._LOCALE_: en
>>> 2017-02-08 22:49:10,897 DEBUG [deformdemo:63][waitress] locale_name from
>>> default_locale_negotiator: de
>>> 2017-02-08 22:49:10,897 DEBUG [deformdemo:2080][waitress] locale_name:
>>> de, request._LOCALE_: de
>>> 2017-02-08 22:49:12,345 DEBUG [deformdemo:63][waitress] locale_name from
>>> default_locale_negotiator: nl
>>> 2017-02-08 22:49:12,345 DEBUG [deformdemo:2080][waitress] locale_name:
>>> nl, request._LOCALE_: nl
>>>
>>> I've uploaded it here: https://github.com/frispete/deformdemo
>>>
>>> Could somebody more familiar with the pyramid translation machinery be
>>> so kind to have a look into this?
>>>
>>> Thanks in advance,
>>> Pete
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "pylons-devel" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to pylons-devel+unsubscr...@googlegroups.com.
>>> To post to this group, send email to pylons-devel@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/pylons-devel.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] i18n in deformdemo dysfunctional

[Michael Merickel]

I noticed that the renderer is not being used. The
`deform.Form.set_default_renderer(render)` is commented out. Uncommenting
it doesn't solve the problem but it's definitely an issue as the
zpt_renderer isn't actually being used as a result.

On Wed, Feb 8, 2017 at 4:14 PM, Michael Merickel <mmeri...@gmail.com> wrote:

> The issue is *usually* that the TranslationString instance hasn't been run
> through `request.localizer.translate(..)`. Now, why not? I haven't dug in
> to try and figure that out yet.
>
> On Wed, Feb 8, 2017 at 3:55 PM, Hans-Peter Jansen <h...@urpla.net> wrote:
>
>> Hi,
>>
>> I've used a good part of the day for getting i18n fixed in deformdemo,
>> but failed so far. :(
>>
>> While all debug instrumentation show green lights, the translation
>> strings aren't picked up for some reason:
>>
>> 2017-02-08 22:49:07,717 DEBUG [deformdemo:63][waitress] locale_name from
>> default_locale_negotiator: de
>> 2017-02-08 22:49:07,718 DEBUG [deformdemo:2080][waitress] locale_name:
>> de, request._LOCALE_: de
>> 2017-02-08 22:49:09,795 DEBUG [deformdemo:63][waitress] locale_name from
>> default_locale_negotiator: en
>> 2017-02-08 22:49:09,795 DEBUG [deformdemo:2080][waitress] locale_name:
>> en, request._LOCALE_: en
>> 2017-02-08 22:49:10,897 DEBUG [deformdemo:63][waitress] locale_name from
>> default_locale_negotiator: de
>> 2017-02-08 22:49:10,897 DEBUG [deformdemo:2080][waitress] locale_name:
>> de, request._LOCALE_: de
>> 2017-02-08 22:49:12,345 DEBUG [deformdemo:63][waitress] locale_name from
>> default_locale_negotiator: nl
>> 2017-02-08 22:49:12,345 DEBUG [deformdemo:2080][waitress] locale_name:
>> nl, request._LOCALE_: nl
>>
>> I've uploaded it here: https://github.com/frispete/deformdemo
>>
>> Could somebody more familiar with the pyramid translation machinery be
>> so kind to have a look into this?
>>
>> Thanks in advance,
>> Pete
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "pylons-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to pylons-devel+unsubscr...@googlegroups.com.
>> To post to this group, send email to pylons-devel@googlegroups.com.
>> Visit this group at https://groups.google.com/group/pylons-devel.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] i18n in deformdemo dysfunctional

[Michael Merickel]

The issue is *usually* that the TranslationString instance hasn't been run
through `request.localizer.translate(..)`. Now, why not? I haven't dug in
to try and figure that out yet.

On Wed, Feb 8, 2017 at 3:55 PM, Hans-Peter Jansen  wrote:

> Hi,
>
> I've used a good part of the day for getting i18n fixed in deformdemo,
> but failed so far. :(
>
> While all debug instrumentation show green lights, the translation
> strings aren't picked up for some reason:
>
> 2017-02-08 22:49:07,717 DEBUG [deformdemo:63][waitress] locale_name from
> default_locale_negotiator: de
> 2017-02-08 22:49:07,718 DEBUG [deformdemo:2080][waitress] locale_name: de,
> request._LOCALE_: de
> 2017-02-08 22:49:09,795 DEBUG [deformdemo:63][waitress] locale_name from
> default_locale_negotiator: en
> 2017-02-08 22:49:09,795 DEBUG [deformdemo:2080][waitress] locale_name: en,
> request._LOCALE_: en
> 2017-02-08 22:49:10,897 DEBUG [deformdemo:63][waitress] locale_name from
> default_locale_negotiator: de
> 2017-02-08 22:49:10,897 DEBUG [deformdemo:2080][waitress] locale_name: de,
> request._LOCALE_: de
> 2017-02-08 22:49:12,345 DEBUG [deformdemo:63][waitress] locale_name from
> default_locale_negotiator: nl
> 2017-02-08 22:49:12,345 DEBUG [deformdemo:2080][waitress] locale_name: nl,
> request._LOCALE_: nl
>
> I've uploaded it here: https://github.com/frispete/deformdemo
>
> Could somebody more familiar with the pyramid translation machinery be
> so kind to have a look into this?
>
> Thanks in advance,
> Pete
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/pylons-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] i18n state of affairs

[Michael Merickel]

One more thing I should add since you mentioned jinja2 and you may not have
seen this yet:

https://github.com/domenkozar/pyramid-cookiecutter-jinja2

The pyramid_jinja2 cookiecutter actually has some integrated i18n support
that works. We have thrown around some ideas on merging that into the
default starter scaffold [1], but I'm afraid that we don't yet have the
"best practice" defined and would want it to be synchronized with whatever
pyramid discusses in its docs [2].

[1] https://github.com/Pylons/pyramid_jinja2/issues/139
[2] http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/i18n.html


On Wed, Feb 8, 2017 at 3:31 PM, Hans-Peter Jansen <h...@urpla.net> wrote:

> Hi Michael,
>
> On Mittwoch, 8. Februar 2017 12:22:27 Michael Merickel wrote:
> > On Wed, Feb 8, 2017 at 11:36 AM, Hans-Peter Jansen <h...@urpla.net>
> wrote:
> > > As a consequence, all these packages will depend on lingua then..
> >
> > Do the packages actually need to depend on lingua? I see that your PR to
> > deform doesn't add it, however deform expects it to in the dev
> environment
> > (tests, running i18n.sh, etc). I'm just trying to clarify if you're
> saying
> > it would be a new runtime dependency.
>
> AFAICS, it's not a runtime dependency, it's needed for i18n work only (as
> long
> as the mo files are tarred up)..
>
> > > One downside of this move: jinja2 support depends on babel, and needs
> some
> > > configuration file support for pot-create, that has to be patched into
> > > i18n.sh
> >
> > > before:
> > The quick history here, as I know it:
> >
> > - Pyramid, etc shipped using babel for everything.
> > - Babel didn't support py3.
> > - For that reason and I'm sure many other reasons, Wichert created lingua
> > and submitted a few PRs to pyramid to start using it in the
> documentation.
>
> Thanks for the intro. Yeah, I know, Armin Ronacher add his Py3 crusade..
>
> > I personally don't know what the state of the art is now that babel
> > supports py3 I haven't needed to write a fully i18n app myself and so my
> > knowledge is only limited to diving in and fixing certain bugs or
> reviewing
> > PRs.
>
> I'm just starting with Pyramid (ahem, websauna) in a project, that
> essentially
> needs full i18n support.. Therefor, I try to wrap my head around all these
> loose ends ATM. Not that easy, because the web is full of misleading
> information in this regard as well.
>
> Since I cannot depend on hearsay, I started with the simplest possible
> task,
> having a pyramid-cookiecutter-starter project localized. Since that uses
> jinja2 templating only, babel is sufficient. Adding deform makes lingua
> necessary, since babel doesn't support chameleon templates (to my
> knowledge).
> lingua depends on babel, when it comes to jinja2 extraction. Oh, well..
>
> Sorry for not having expressed that from the beginning.
>
> > I very much appreciate your work on this and would love to see things get
> > standardized and modernized. I've had several people ask in #pyramid on
> IRC
> > why things are not working as our docs kinda sort of tell you to use both
> > babel and lingua without definitively explaining anything as I think they
> > were only partially updated when switching to lingua.
>
> Maybe, with your insight into Pyramid and my intention to have a properly
> working i18n in _all_ these packages, we can tidy up that mess a bit.
>
> As of now, I don't see the need for babel and lingua as runtime
> dependencies
> at all. babel brings in a lot of useful things, that a fully localized app
> can
> make use of, but none of that is used in the mentioned packages ATM.
> lingua is
> created for message extraction only (with a script called pot-create). I
> can
> add a test to i18n to check, if pot-create exists, and bail out with an
> installation hint otherwise.
>
> In order to make the translation infrastructure universally useful, we can:
>  * add the i18n.sh script
>  * ask for installation of babel and lingua, if one is missing
>  * add a lingua.cfg:
>
> [extractor:xml]
> default-engine = tales
>
> [extractor:chameleon]
> default-engine = tales
>
> [extensions]
> .jinja2 = babel-jinja2
> .mako = babel-mako
>
>
> Working with translations would boil down to:
>  * create language: ./i18n.sh lang
>  * everything else: ./i18n.sh
>
> By default, neither babel nor lingua is a runtime dependency.
>
> Cheers,
> Pete
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To unsubscribe from this group and stop receiving emails from it,

Re: [pylons-devel] i18n state of affairs

[Michael Merickel]

On Wed, Feb 8, 2017 at 11:36 AM, Hans-Peter Jansen  wrote:

> As a consequence, all these packages will depend on lingua then..
>

Do the packages actually need to depend on lingua? I see that your PR to
deform doesn't add it, however deform expects it to in the dev environment
(tests, running i18n.sh, etc). I'm just trying to clarify if you're saying
it would be a new runtime dependency.


> One downside of this move: jinja2 support depends on babel, and needs some
> configuration file support for pot-create, that has to be patched into
> i18n.sh
> before:
>

The quick history here, as I know it:

- Pyramid, etc shipped using babel for everything.
- Babel didn't support py3.
- For that reason and I'm sure many other reasons, Wichert created lingua
and submitted a few PRs to pyramid to start using it in the documentation.

I personally don't know what the state of the art is now that babel
supports py3 I haven't needed to write a fully i18n app myself and so my
knowledge is only limited to diving in and fixing certain bugs or reviewing
PRs.

I very much appreciate your work on this and would love to see things get
standardized and modernized. I've had several people ask in #pyramid on IRC
why things are not working as our docs kinda sort of tell you to use both
babel and lingua without definitively explaining anything as I think they
were only partially updated when switching to lingua.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Make Pyramid 1.7 scaffolds ready for naïve usage of py.test and tox in new projects?

[Michael Merickel]

Hey Vincent, thanks for working on this.

It would be very helpful if you could open an issue or a PR on github as
it's much easier to discuss things there. I will say up front that a couple
of these decisions are made already.

1) no tox. This is an app, not a library and we've already had a couple
discussions about this where it was decided we would not promote tox in the
scaffolds.
2) no explicit location where tests must live, I'd opt for scanning the
project for particular conventions such as files starting with ``test_``.

As far as adding a setup.cfg or a pytest.ini, I'm all for these things if
they make running the tests simpler but avoid certain opinions like package
layout. I'm not sure what coverage settings you'd need so I'd have to see
the PR.

- Michael


On Thu, May 5, 2016 at 11:44 AM, Vincent Férotin 
wrote:

> Hi, Pyramid developers!
>
> Here are some thoughts about what I consider a small problem for new users:
> while usage of py.test is now promoted in documentation
> (
> http://docs.pylonsproject.org/projects/pyramid/en/1.7-branch/whatsnew-1.7.html#documentation-enhancements
> )
> scaffolds are not ready for naive usage of py.test by new comers to
> Pyramid,
> i.e. running ``py.test [--cov]`` at new project's root collects no tests.
>
> As I don't know if this could be considered a bug, I'd prefer opening
> discussion here, before opening a bug in the tracker or submitting a pull
> request.
>
> What I, as new Pyramid user, attempt just after creating project via
> ``pcreate -s [scaffold] [myproject]``,
> and seeing the "Welcome to Pyramid.  Sorry for the convenience." message,
> is that
> project is ready to be tested out of the box by py.test or tox at
> project's root.
> Currently, this seems to not be the case: py.test collects no item
> (outputs "collected 0 items").
>
> To change that, I tried to modify `alchemy` scaffold so that:
> - py.test runs out-of-the-box,
> - little effort is required for tox to also work.
>
> To do that, I:
> - add a `tox.ini` configuration file for py.test;
> - add a `.coveragerc` configuration file for pytest-cov plugin;
> - move all tests material in its own directory (``{{pacakge}}/tests/``);
> - split test file in `tests/base.py` and `tests/test_myview.py`.
> Full change could be found here:
>
> https://github.com/vincent-ferotin/pyramid/commit/7240f2214509bfb3b9b1aa0705f2021808d4dd5e
>
> Discuss-able choices I'm aware of are:
> * usage of tox.ini in place of setup.cfg:
>   as setup.cfg generation was removed from 1.7, and usage of tox could be
> possible,
>   I've preferred putting py.test configuration in tox.ini.
>   This allows small change (i.e. adding ``[tox] envlist=py35``) for also
> having tox running on the new project;
> * moving tests on their own sub-directory:
>   This avoids py.test scanning all project's files in order to collect
> tests, which could be perceived as slow,
>   by explicitly telling it where tests stand.
>   Also, this allow splitting tests into material for testing
> (`tests/base.py`) to tests them selves (`tests/test_*.py`),
>   in same manner than models is splitted between `models/meta.py` and
> `models/mymodel.py`.
>
> So, what do you guys think about that?
>
> -- Vincent
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/pylons-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Re: request context for Sentry

[Michael Merickel]

I'm missing something here probably but the raven docs have pretty
straightforward support for configuring it via the ini file. Have you tried
this?

https://docs.getsentry.com/hosted/clients/python/integrations/pyramid/#pastedeploy-filter

On Sat, Mar 19, 2016 at 5:44 PM, Zsolt Ero  wrote:

> Thanks, I was able to make a working client, but not using the pipeline +
> filter part in the ini, but by wrapping app by:
>
> from raven import Client
>
> from raven.middleware import Sentry
>
> client = Client('https://...:...@app.getsentry.com/
> ...')
>
> app = Sentry(app, client=client)
>
> This way client is configured on init and captureException works
> automatically.
>
>
>
>
> Friday, March 18, 2016 at 1:26:39 AM UTC+1, Zsolt Ero wrote:
>>
>> Thanks, I see. I believe this way I do not need the .ini part, do I?
>>
>> On Thursday, March 17, 2016 at 3:40:28 AM UTC+1, Jonathan Vanasco wrote:
>>>
>>>
>>>
>>> On Wednesday, March 16, 2016 at 9:36:44 PM UTC-4, Zsolt Ero wrote:

 David Cramer from Sentry replied to me that if Sentry is used with the
 middleware, then it should automatically receive the WSGI context:
 from sentry.middleware import Sentry

 application = Sentry(application, client=Client(dsn, ...))

 My problem is that in Pyramid I have no idea where could I get an
 application, or if this would work at all.

>>>
>>> That looks like the initial app setup in your `project/__init__.py`
>>>
>>> `application` would be what is returned from config.make_wsgi_app()
>>>
>>> Some people do "return config.make_wsgi_app()"
>>>
>>> Others prefer "app = config.make_wsgi_app()", then wrap it in middleware
>>>
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/pylons-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] PasteDeploy in the Pylons GitHub org?

[Michael Merickel]

On Tue, Mar 8, 2016 at 5:55 PM, Marc Abramowitz  wrote:
>
> To be honest, I'm not sure I want to be solely responsible for it myself
> either. I was hoping that if it was under the Pylons project, that would
> allow more people to chip in, as needed.
>

The Pylons Project repositories still need to have a maintainer / point of
contact to manage releases and code reviews. That is not something that is
automated. Aside from kotti and webtest the project releases and code
reviews are managed almost 100% by me, Bert and Tres with a lot of people
popping their heads in once in a while along with Steve doing yeoman's work
on documentation. We are always excited for anyone looking to help but
that's just the way things are right now so taking on another project
really does need to have someone willing to learn the codebase and work on
it when necessary.


> Someone a while back also mentioned the possibility of just pulling
> whatever bits of PasteDeploy that Pyramid needs into Pyramid itself. I have
> not looked into what that would entail however. Might be a lot of code and
> I don't think the PasteDeploy code is super well-tested so that might
> involve writing lots of tests.
>

I think with the advent of montague by Joe Rosenbaugh as well as 12-factor
app design I know, personally, that I'm ready to start having a
conversation about what to do in this space. PasteDeploy is definitely a
point of contention amongst the users of Pyramid and bringing it into core
will not be happening. It's already an issue that our CLI tools are
dependent on the ini files and I think these are things that everyone
wishes were fixed but we've never had a discussion on coming up with a
standard solution because everyone has their own use-cases to deal with.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

[pylons-devel] github pages for pylons project sites

[Michael Merickel]

Hey everyone, I'm starting the discussion (which I hope is very quick)
about what to do with our public websites.

Right now we have:

- docs.pylonsproject.org (docs, hosted on rtd)
- docs.pylonsproject.org/projects (hosted on rtd)
- www.pylonsproject.org (ppo, hosted somewhere controlled by blaise/ben)
- trypyramid.com (tpc, hosted somewhere I have no idea)
- webob.org (hosted somewhere I have no idea)
- docs.webob.org (hosted on rtd)

I think Blaise is the only person with access to DNS configurations but I'm
not really sure.

I'd like to propose moving several sites over to github pages for easier
management and update the DNS records with CNAME records to the github
pages sites. All of the sites are static and it would allow master to be
always live, as well as control deployment permissions via the standard
github.com/Pylons membership levels.

The sites I'd like to see updated are:

- www.pylonsproject.org
- trypyramid.com
- webob.org

Can anyone give me a reason to not go this route?

- Michael

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] github pages for pylons project sites

[Michael Merickel]

Okay, I was unaware of any on-going changes on the sites which is a little
silly for someone with my level of involvement in the project.

Blaise, could you please explain the setup you are currently working on -
including a timeline, what websites it will affect, how team members will
be able to use it and what will happen when you are hit by a bus?

I'm happy to withdraw my github pages proposal if we have something that
works well but I was unaware anything was actually happening! This is
something I'd like to help with, especially with regards to the actual
hosting configuration.

- Michael


On Sat, Jan 2, 2016 at 3:33 PM, Blaise Laflamme <bla...@laflamme.org> wrote:

> Contributor should be able to compile and see their own changes before
> they submit PRs, and we should do the same when reviewing. The dev branch I
> was proposing earlier was to help us merging PR and make sure we don't
> publish unfinished work on master.
>
> On Saturday, January 2, 2016 at 4:28:29 PM UTC-5, Steve Piercy wrote:
>>
>> On 1/2/16 at 3:11 PM, mmer...@gmail.com (Michael Merickel) pronounced:
>>
>> >Hey everyone, I'm starting the discussion (which I hope is very quick)
>> >about what to do with our public websites.
>> >
>> >Right now we have:
>> >
>> >- docs.pylonsproject.org (docs, hosted on rtd)
>> >- docs.pylonsproject.org/projects (hosted on rtd)
>> >- www.pylonsproject.org (ppo, hosted somewhere controlled by
>> blaise/ben)
>> >- trypyramid.com (tpc, hosted somewhere I have no idea)
>> >- webob.org (hosted somewhere I have no idea)
>> >- docs.webob.org (hosted on rtd)
>> >
>> >I think Blaise is the only person with access to DNS configurations but
>> I'm
>> >not really sure.
>> >
>> >I'd like to propose moving several sites over to github pages for easier
>> >management and update the DNS records with CNAME records to the github
>> >pages sites. All of the sites are static and it would allow master to be
>> >always live, as well as control deployment permissions via the standard
>> >github.com/Pylons membership levels.
>> >
>> >The sites I'd like to see updated are:
>> >
>> >- www.pylonsproject.org
>> >- trypyramid.com
>> >- webob.org
>> >
>> >Can anyone give me a reason to not go this route?
>>
>> +1, but with a concern for the non-doc/HTML-only/marketing
>> sites.  How do we preview proposed changes with as much ease as
>> deploying to a production environment?
>>
>> Taking trypyramid.com as an example, I could set up a CNAME of
>> trypyramid.stevepiercy.com, and point it at a particular branch
>> of stevepiercy/tpc before submitting a PR to Pylons/tpc.  But
>> this would raise a bar for new individual contributions.
>>
>> Perhaps we declare a branch 'dev' or 'staging' for reviewing
>> proposed changes, and set up a CNAME for each marketing website?
>>
>> --steve
>>
>> 
>> Steve Piercy, Soquel, CA
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/pylons-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] github pages for pylons project sites

[Michael Merickel]

Which websites are you planning to affect in the short term? Is it the 3 I
originally listed? I expect Bert will be happy if webob.org is on the list.

On Sat, Jan 2, 2016 at 4:03 PM, Blaise Laflamme <bla...@laflamme.org> wrote:

> Sure,
>
> the initial setup is pretty simple, Linode VPS running Ubuntu 14.04 with
> latest Nginx-stable. A pylons user, with public user keys for site
> publishing, responsible to publish via pushing master branch to prod
> deployment, and probably dev branch for dev deployment.
>
> The setup will be done this weekend, so expect to have it in place early
> next week.
>
> I've created a Pylons account on Linode so we can have multiple to access
> the console and DNS, it's not tied to me.
>
> As soon as I'm done I'll share with all responsible people the
> informations, and then we'll just have to write down some procedure and
> workflow about this.
>
>
> On Saturday, January 2, 2016 at 4:54:28 PM UTC-5, Michael Merickel wrote:
>>
>> Okay, I was unaware of any on-going changes on the sites which is a
>> little silly for someone with my level of involvement in the project.
>>
>> Blaise, could you please explain the setup you are currently working on -
>> including a timeline, what websites it will affect, how team members will
>> be able to use it and what will happen when you are hit by a bus?
>>
>> I'm happy to withdraw my github pages proposal if we have something that
>> works well but I was unaware anything was actually happening! This is
>> something I'd like to help with, especially with regards to the actual
>> hosting configuration.
>>
>> - Michael
>>
>>
>> On Sat, Jan 2, 2016 at 3:33 PM, Blaise Laflamme <bla...@laflamme.org>
>> wrote:
>>
>>> Contributor should be able to compile and see their own changes before
>>> they submit PRs, and we should do the same when reviewing. The dev branch I
>>> was proposing earlier was to help us merging PR and make sure we don't
>>> publish unfinished work on master.
>>>
>>> On Saturday, January 2, 2016 at 4:28:29 PM UTC-5, Steve Piercy wrote:
>>>>
>>>> On 1/2/16 at 3:11 PM, mmer...@gmail.com (Michael Merickel) pronounced:
>>>>
>>>> >Hey everyone, I'm starting the discussion (which I hope is very quick)
>>>> >about what to do with our public websites.
>>>> >
>>>> >Right now we have:
>>>> >
>>>> >- docs.pylonsproject.org (docs, hosted on rtd)
>>>> >- docs.pylonsproject.org/projects (hosted on rtd)
>>>> >- www.pylonsproject.org (ppo, hosted somewhere controlled by
>>>> blaise/ben)
>>>> >- trypyramid.com (tpc, hosted somewhere I have no idea)
>>>> >- webob.org (hosted somewhere I have no idea)
>>>> >- docs.webob.org (hosted on rtd)
>>>> >
>>>> >I think Blaise is the only person with access to DNS configurations
>>>> but I'm
>>>> >not really sure.
>>>> >
>>>> >I'd like to propose moving several sites over to github pages for
>>>> easier
>>>> >management and update the DNS records with CNAME records to the github
>>>> >pages sites. All of the sites are static and it would allow master to
>>>> be
>>>> >always live, as well as control deployment permissions via the
>>>> standard
>>>> >github.com/Pylons membership levels.
>>>> >
>>>> >The sites I'd like to see updated are:
>>>> >
>>>> >- www.pylonsproject.org
>>>> >- trypyramid.com
>>>> >- webob.org
>>>> >
>>>> >Can anyone give me a reason to not go this route?
>>>>
>>>> +1, but with a concern for the non-doc/HTML-only/marketing
>>>> sites.  How do we preview proposed changes with as much ease as
>>>> deploying to a production environment?
>>>>
>>>> Taking trypyramid.com as an example, I could set up a CNAME of
>>>> trypyramid.stevepiercy.com, and point it at a particular branch
>>>> of stevepiercy/tpc before submitting a PR to Pylons/tpc.  But
>>>> this would raise a bar for new individual contributions.
>>>>
>>>> Perhaps we declare a branch 'dev' or 'staging' for reviewing
>>>> proposed changes, and set up a CNAME for each marketing website?
>>>>
>>>> --steve
>>>>
>>>> 
>>>> Steve Piercy, Soquel, CA
>>>>
>>&

Re: [pylons-devel] including debugtoolbar support in plugins

[Michael Merickel]

I already added the initial hook for this via debugtoolbar.includes. In
theory you could add extra panel packages that defined an includeme(config)
and they can do whatever they want.

development.ini
---

debugtoolbar.includes =
myapp.debug.custom_panel

myapp/debug/custom_panel.py
---

def includeme(config):
config.add_debugtoolbar_panel(CustomPanel)

class CustomPanel(...):

The required changes to fully support doing certain things would be to
expose a few config directives that do not currently exist. For example,
config.add_debugtoolbar_panel() which would add the panel to the list of
default panels. That includeme is also the best place to add custom routes,
etc to define ajax urls, or inject extra static assets into the panel UI,
making them available.

Ideally there would also be some sort of
config.add_debugtoolbar_panel_css() which would add an extra css file to be
added, or config.add_debugtoolbar_panel_javascript() to add a 

Re: [pylons-devel] Re: wsgi server of choice?

[Michael Merickel]

On Tue, Oct 20, 2015 at 12:29 PM, Chris Withers 
wrote:

> What does pserve use?


pserve is a generic runner. It uses whatever server is pointed to in the
[server:main] section by default. This is taken care of by PasteDeploy as
part of loading the ini file.

- Michael

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Paste #urlmap and console scripts don't seem to be working correctly.

[Michael Merickel]

Pyramid has no way to know which pyramid app you are referring to in
bootstrap unless you specify the section. As pyramid at a fundamental
level supports running multiple apps in the same process you have to
handle this yourself outside if you need to load a specific app for
your script to run.

The config_uri supports specifying the section without your patch. You
just do bootstrap('development.ini#project'). By default it uses main
of course, and after that it falls back to loading the last pyramid
app created logic which is what's finding your support app right now.
If this isn't working for you then you should be specifying the
section in your scripts.

On Wed, Jul 22, 2015 at 2:09 PM, Chip Kellam c...@honey.is wrote:
 I have defined my config.ini file as such using the paste urlmap guidelines
 for creating this type of application:

 [composite:main]
 use = egg:Paste#urlmap
 / = project
 domain developer.domain.com / = dev
 domain support.domain.internal / = support   # Internal/VPN-only URL

 [app:project]
 use = egg:project

 [app:dev]
 paste.app_factory = dev:main

 [app:support]
 paste.app_factory = support:main


 support is a new module we just wrote to allow our CSRs to manage data
 through a CRUD-style interface.  However, when I added this 3rd app (dev
 has been there for a while), Pyramid now bootstraps that app in console
 scripts INSTEAD of project.  I can tell because when I run: proutes
 config.ini, I see the support routes and NOT the project routes.

 I'm using the standard:

 from pyramid.paster import bootstrap
 env = bootstrap(config_uri)

 I did notice if I monkey patch bootstrap and pass in the app name I want, it
 works fine, e.g:

 def bootstrap(config_uri, request=None, options=None, name='main'):
 app = get_app(config_uri, name=name)
 env = prepare(request)
 env['app'] = app
 return env


 Any idea why this would be occurring??  I'd rather not do anything hacky
 with the core pyramid code, but this is affecting all of the logic in our
 scripts that deal with any custom app configurations.

 Thanks for your help!

 -Chip

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to pylons-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-devel.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Knob for ACLAuthorizationPolicy?

[Michael Merickel]

It seems to me that allowing this to be modified is fairly harmless.
Would you expect it to fallback to __acl__ if it doesn't find the
custom method/attribute? Or would you expect it to be changed
wholesale? The issue in changing it wholesale and still calling it the
ACLAuthorizationPolicy is that it may be difficult to use with any
third party code but that's kind of an issue with any code written to
a particular policy.

On Fri, Jul 17, 2015 at 10:19 AM, Iain Duncan iainduncanli...@gmail.com wrote:
 This sounds like it would actually be helpful for me too for the project
 we're about to embark on, if I'm understanding the OP correctly.

 my two cents Canadian!
 iain

 On Thu, Jun 11, 2015 at 10:04 AM, Chris McDonough chr...@plope.com wrote:

 Id like to hear other people speak up who have needed the same knob. If
 this is something a few people have needed, I'd ask them if their life would
 be much better with a knob on aclauthorizationpolicy instead of a custom
 policy given that they would also need to document it and justify it in
 the.pyramid docs.

 On June 11, 2015 11:28:25 AM EDT, Christian Theune
 christian.the...@googlemail.com wrote:

 Hi,

 I am implementing an application that is structured in way where I have a
 business model and multiple Pyramid applications on top of that, ending up
 with 4 processes, two of them providing APIs (XML-RPC) and two of them
 providing UIs.

 I'm happy using the ACLAuthenticationPolicy but I noticed that my __acl__
 methods are getting convoluted as they have to know about the various
 processes. I wanted to split this up and wondered why the
 ACLAuthorizationPolicy can't be customized to use different attributes for
 the lookup.

 I'm making separate instances of the ACLAuthorizationPolicy in those
 applications and thus I started out to customize it, but had to copy the
 whole class. The ACL system itself seems fine for me, but putting the
 variations of ACLs that I'm dealing with into the same __acl__ is ... well
 ... convoluted.

 Chris pointed out that adding knobs isn't that fashionable - but I
 AFAICT I'm happy with the ACLAuthorizationPolicy except this one bit. I
 know this isn't necessarily a strong argument but maybe somone can tell me
 whether I'm doing something wrong or maybe help me to work towards a no
 knobs needed solution. :)

 Cheers,
 Theuni


 --
 Sent from my Android device with K-9 Mail. Please excuse my brevity.

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to pylons-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-devel.
 For more options, visit https://groups.google.com/d/optout.


 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to pylons-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-devel.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] debugtoolbar - panel/toolbar API-- feedback wanted.

[Michael Merickel]

I started to lay the groundwork for this in
https://github.com/Pylons/pyramid_debugtoolbar/pull/182 by making the
panel name a unique identifier that can be used in more places. This
work probably needs to be completed but I did it on that panel
activation branch which has some real problems waiting to be solved.
We would probably take that work and provide some sort of
find_panel(name) api which would possibly solve most of your
complaints.

On Tue, Dec 16, 2014 at 11:25 AM, Jonathan Vanasco
jonat...@findmeon.com wrote:
 I had an idea a while back for a Toolbar - Panel api, and I think I need
 to build it out.  hoping someone here can set me straight and offer some
 better ideas on how to pull this off.

 The simple idea:
 1.  Give each panel a `toolbar` attribute after instantiation.  this
 would allow any panel to loop through the toolbar's panels, and access the
 information on another one.
 2.  add a config.scan in __init__.py for panels/

 Why?
 The toolbar panels generally work by stashing a lot of information on
 the request object, this is a lot of great info -- but only accessible to
 the panel itself.  If panels could find one another (and a new view could be
 added), it would be trivial to do things like creating an API endpoint that
 can pull that data out.

 This is my practical use-case example:  The unit test that ensures all my
 routes work also times the pages; a few pages have shown troubling times and
 I need to inspect them.  Just about all the information I need is in the
 Performance and SqlAlchemy panels.  It would be fairly simple to piggyback
 on all the work done by the debugtoolbar team, and simply parse the pDebug
 link from the response, then have a followup request pull the data from an
 endpoint and save it to a text file.

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to pylons-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-devel.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Adding custom files to be watched by pserve --reload

[Michael Merickel]

pyramid.scripts.pserve.watch_file and
pyramid.scripts.pserve.add_file_callback exist for this purpose.
Unfortunately it doesn't look like they are in the docs atm but I
think you can expect them to stick around. See
https://github.com/Pylons/pyramid/blob/cc15bbf7de74f4cdfc676e34fa429d2658d1ddf6/pyramid/scripts/pserve.py#L767-L776
for more info.

On Tue, Dec 9, 2014 at 12:35 PM, Piotr Dobrogost
p...@google-groups-2014.dobrogost.net wrote:
 Hi!

 I've been using paste.reloader.watch_file() function
 (http://pythonpaste.org/modules/reloader.html) to add custom config files to
 be watched for changes during development.
 Is something like this possible in Pyramid?


 Regards,
 Piotr Dobrogost

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to pylons-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-devel.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Re: pcreate: Uppercase version of the package name?

[Michael Merickel]

AFAIK all of the things you are asking for are possible using the
(documented) scaffolding API. You basically just subclass
``PyramidTemplate`` and override ``pre`` to mutate the ``vars`` and
add what you like.

http://docs.pylonsproject.org/projects/pyramid/en/1.5-branch/narr/scaffolding.html

http://docs.pylonsproject.org/projects/pyramid/en/1.5-branch/api/scaffolds.html#pyramid.scaffolds.PyramidTemplate.pre

On Tue, Nov 25, 2014 at 10:14 AM, Jonathan Vanasco
jonat...@findmeon.com wrote:
 I would create an Issue and propose it on the Github.  One of the core
 maintainers will say something like Great!, Maybe... or  No way.  I've
 seen (and personally gotten) a lot more No Way than Okay for proposed
 changes.

 This is such an edge case though, that I don't know if they'll go for it
 as-is.  Why would other people need or use this?  I don't see it getting
 added unless you can come up with a compelling reason.

 This is purely a guess - but I think you might have better luck proposing it
 as some sort of hook for pcreate.  i.e., if there was some way to pass in
 other template variables to pcreate.


 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to pylons-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-devel.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] static_url usage

[Michael Merickel]

You'll want to avoid changing the path in your usage of static_url.
Fortunately, Pyramid supports overriding static assets, so you can
make a dummy path and override that with your dev or production real
asset path.

config.add_static_view('images', 'p_started:webapp/images')
config.override_asset(to_override='p_started:webapp/images/',
override_with='p_started:webapp/dist/images')

request.static_url('p_started:webapp/images/pyramid.png')


On Sat, Aug 16, 2014 at 3:23 PM, davide moro davide.m...@gmail.com wrote:



 2014-08-16 6:59 GMT+02:00 Karl O. Pinc k...@meme.com:

 Hello,

 On 08/15/2014 05:39:51 PM, davide moro wrote:
  Is there a way to generate a static url using the name images
  registered
  in add_static_view?
  I mean:
   ${request.static_url('p_started:images/pyramid.png')}
  instead of:
   ${request.static_url('p_started:webapp/app/images/
  pyramid.png')}
  I want to use the name because the path will change depending on the
  deployment settings.

 I don't know how to do what you want, and am not particularly
 experienced with pyramid.  But if the path changes based
 on deployment settings why not use the deployment settings
 value everywhere and make that relationship explicit?

 In the .ini:

 minify=app

 Then in the code:

   config.add_static_view('images',
  , 'p_started:webapp/'
+ config.registry.settings['minifiy']
+ '/images'
  , cache_max_age=3601)


 And:


   ${request.static_url('p_started:images/'
+ request.registry.settings['minifiy']
+ '/images')


 Hi Karl!

 Thank you for your tips, I hoped to avoid this workaround.

 Anyway for me it sounds like a weird behaviour of static_url. I'm not sure
 but probably its parameter should be bound to the name registered in
 add_static_view because:
 * if you want to construct a url you should know the exact path associated
 to the name (webapp/app/images)
 * if you change the path of your assets you'll have to change all your
 templates code
 * when you construct by hand an url of a static resource you just digit
 http://localhost:6543/images/pyramid.png and not webapp/app/etc

 Or not? What do you think about that?

 Thank you!

 davide

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to pylons-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-devel.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Bugs in SessionAuthenticationPolicy

[Michael Merickel]

It sounds like you are not using the
`pyramid.security.remember(request, userid)` API to store the user in
the session. If you would like to store the userid directly you may but
you are circumventing the pyramid authentication APIs. As far as the
authenticated_userid, this will invoke your callback, but only if a
userid is found in the session in the first place (otherwise no one is
logged in and it short-circuits). unauthenticated_userid will return
the id directly found in the session and is mainly there as a hop
between the raw session and your callback.

On Tue, Aug 5, 2014 at 11:34 PM, Karl O. Pinc k...@meme.com wrote:
 Hi,

 I'm using pyramid 1.5.1 and in trying to figure
 out SessionAuthenticationPolicy I found problems.
 I looked at HEAD (I think) on github and problems
 seem to exist there too.

 unauthenticated_userid is not documented.


 The callback function is never called.  The
 debug output is:

 2014-08-06 02:59:43,213 DEBUG [testlogin][Dummy-3]
 pyramid.authentication.SessionAuthenticationPolicy.effective_principals:
 unauthenticated_userid returned None; returning ['system.Everyone']

 The problem is that SessionAuthenticationPolicy
 is counting on having a prefix + 'userid'
 session key in request.session.  However there's
 no documentation on this and so the key does not exist.

 One possible approach is to supply an identity
 keyword argument in a fashion similar to that
 in ReposeWho1AuthenticationPolicy so the
 user knows what key is supposed to exist.
 (This seems heavy-handed.)

 I'm not really thinking things through at
 the moment but it seems to me that there
 needs to be some sort of documentaion,
 if not an interface, for setting the value
 behind
 SessionAuthenticationPolicy.(un)authenticated_userid.
 Or something.

 As it is SessionAuthenticationPolicy is
 impossible to use without snooping through
 the source.

 Sorry to run-on.  I've been working at
 this for a while and my brain is full.

 Meanwhile, if I simply set
 request.session[prefix + 'userid']
 in my app will I be reasonably
 future-proof?  (I've not actually tried this
 to see if it works.)

 Thanks.

 Karl k...@meme.com
 Free Software:  You don't pay back, you pay forward.
  -- Robert A. Heinlein

 --
 You received this message because you are subscribed to the Google Groups 
 pylons-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to pylons-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-devel.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Probelms with wairtress in Python 2.7.7

[Michael Merickel]

On Thu, Jun 5, 2014 at 11:40 AM, Chris McDonough chr...@plope.com wrote:

 On 06/05/2014 11:49 AM, Bert JW Regeer wrote:

 https://github.com/Pylons/webob/pull/150

 Is an outstanding pull request to fix this in from_file() in WebOb, would
 this solve the problem?


 Probably not.  More like here:

 https://github.com/Pylons/pyramid/blob/master/pyramid/response.py#L55


It may not be bad to just sanitize all headers in start_response or in
_abs_headerlist:

https://github.com/Pylons/webob/blob/master/webob/response.py#L1027

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: some tests fail for pyramid_handlers 0.5

[Michael Merickel]

actually
https://github.com/Pylons/pyramid_handlers/issues


On Mon, Aug 5, 2013 at 7:19 PM, Steve Piercy steve.piercy@gmail.comwrote:

 On 8/5/13 at 11:57 PM, h...@urpla.net (Hans-Peter Jansen) pronounced:

  Dear Chris,
 
  don't know your favorite way to be informed about such issues:

 https://github.com/Pylons/pyramid/issues

 Ideally with a pull request that fixes it.  :D

 Next favored would be here or in IRC.

 --steve


  FYI, building on top of a fairly current pyramid stack, two tests of
  pyramid_handlers fail:
 
  [7s] + python setup.py nosetests --with-coverage
  [7s] running nosetests
  [7s] running egg_info
  [7s] writing requirements to pyramid_handlers.egg-info/requires.txt
  [7s] writing pyramid_handlers.egg-info/PKG-INFO
  [7s] writing top-level names to
 pyramid_handlers.egg-info/top_level.txt
  [7s] writing dependency_links to
 pyramid_handlers.egg-info/dependency_links.txt
  [7s] writing entry points to
 pyramid_handlers.egg-info/entry_points.txt
  [7s] reading manifest file 'pyramid_handlers.egg-info/SOURCES.txt'
  [7s] writing manifest file 'pyramid_handlers.egg-info/SOURCES.txt'
  [7s] running build_ext
  [7s] E.E.
  [7s]
 ==
  [7s] ERROR: test_it (pyramid_handlers.tests.TestHandlerDirective)
  [7s]
 --
  [7s] Traceback (most recent call last):
  [7s]   File
 
 /home/abuild/rpmbuild/BUILD/pyramid_handlers-0.5/pyramid_handlers/tests.py,
 line
  534, in test_it
  [7s] _execute_actions(actions)
  [7s]   File
 
 /home/abuild/rpmbuild/BUILD/pyramid_handlers-0.5/pyramid_handlers/tests.py,
 line
  603, in _execute_actions
  [7s] action['callable']()
  [7s]   File
 /usr/lib/python2.7/site-packages/pyramid/config/views.py, line
  1165, in register
  [7s] order = view_intr['order']
  [7s] KeyError: 'order'
  [7s]
  [7s]
 ==
  [7s] ERROR: test_conflict_add_handler
 (pyramid_handlers.tests.Test_add_handler)
  [7s]
 --
  [7s] Traceback (most recent call last):
  [7s]   File
 
 /home/abuild/rpmbuild/BUILD/pyramid_handlers-0.5/pyramid_handlers/tests.py,
 line
  408, in test_conflict_add_handler
  [7s] self.assertEqual(c[2], 'test_conflict_add_handler')
  [7s] IndexError: list index out of range
  [7s]
  [7s] Name Stmts   Miss  Cover   Missing
  [7s] --
  [7s] pyramid_handlers   106  0   100%
  [7s] pyramid_handlers.tests 475  499%   409, 535-538
  [7s] pyramid_handlers.zcml   26  0   100%
  [7s] --
  [7s] TOTAL  607  499%
  [7s]
 --
  [7s] Ran 36 tests in 0.233s
  [7s]
  [7s] FAILED (errors=2)
 
  Full build log is available here:
 
 https://build.opensuse.org/package/live_build_log/home:frispete:python/python-
  pyramid_handlers/openSUSE_12.2/x86_64
 
  It also shows signs of the intersphinx issue reported an hour ago.
 
  Cheers,
  Pete
 

 
 Steve Piercy, Soquel, CA

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to pylons-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-devel.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: (Help!) small bugs everywhere with polymorphic class-based views

[Michael Merickel]

Huh? Where do you describe the error you're seeing??? You should probably
be calling __init__ on your parent via super or explicitly but it's not
actually a bug since you duplicated the code in both __init__s.


On Sun, Aug 4, 2013 at 1:01 AM, John Cadigan johnpaulcadi...@gmail.comwrote:

 I'm trying to implement polymorphic class-based views, but small errors
 seem to be popping up at random. Especially as the website runs for a
 while. Does it look like I'm taking the right approach to this? In
 particular, am I doing the right thing with in the classe's init? Thanks a
 ton for the awesome framework!


 class BaseView(object):

 *def __init__(self,request):
 self.request = request
 self.response = {}*

 def user_info(self, userid):
 if userid:
 auth_id = DBSession.query(AuthID).filter_by(id=userid).first()
 username = auth_id.display_name
 user_group = str(auth_id.groups[0])
 else:
 username = ''
 user_group = ''
 user_info = {'username':username,
 'group':user_group,'flashcards':flashcards, 'rank': rank}
 return user_info

 def add_user_info(self):
 self.userid = authenticated_userid(self.request)
 headers=''
 self.response = self.user_info(self.userid)

 class ContentView(BaseView):

 *def __init__(self, request):
 self.request = request
 self.response = {}
 self.add_user_info()*

 @reify
 def url(self):
 return self.request.matchdict['curl']

 def view_classroom(self):
 self.response.update(self.add_some_content_method(self.url))
 return self.response

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to pylons-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-devel.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Newbie moving from Webapp2 to Pylons/Pyramids quick questions

[Michael Merickel]

Well pyramid scales down very easily. If you just ignore the stuff you
don't need you will get very far in using it as a minimalist framework.
Pyramid at its lowest levels simply dictates the use of webob's
request/response objects and a particular routing mechanism to get urls to
code (url dispatch or traversal). There are several simple tutorials on
pyramid showcasing some of its features.

http://docs.pylonsproject.org/projects/pyramid_tutorials/en/latest/


On Thu, Jul 25, 2013 at 3:41 PM, ziyuan@gmail.com wrote:

 Hi all,

  I just dove into the world of web development after completion
 various tutorials on googleappengine. My concern is
 that I am a bit overwhelmed by all the high level/intermediate
 functionalities provided by pylons/pyramids. Are there tutorials
 or cookbooks out there just providing info on using pylons or pyramids on
 a lower level? (I like to handle my own cookies/authentications)?
 Thanks in advance.

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to pylons-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-devel.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Simple request history

[Michael Merickel]

I think that if you use a NewResponse subscriber instead of NewRequest that
will be good enough to get what you want. pyramid_beaker commits the
session changes in the response callbacks which happen immediately after
the NewResponse event. So you're probably running into some ordering issue
between response callbacks (yours happening after beaker's).

Finally, this thread probably belongs on pylons-discuss. :-)


On Mon, Jun 24, 2013 at 4:11 PM, Torsten Irländer 
torsten.irlaen...@googlemail.com wrote:

 Hi,

 I need to add a really simple request history in my application and I am
 running in some problems.  The idea is to save a list of URLs
 (request.url) in
 the user session (Beaker).

 So far this is no problem by using a subscriber on NewRequest and adding
 the
 URL to e.g session['history] at the very begin of every new Request.

 But I only want to add the URL in case the request was successful
 (response.status == 200).  I thought this could easily be done by adding
 either a add_finished_callback or  add_response_callback to be able to
 modify the history at the end of the request where I should have access to
 the
 status code.

 Unfortunately it seems not to work as modifications on the session does not
 take effect at this point. Maybe because the request has already been
 processed?

 So you have any ideas how to implement such an easy history?

 Torsten

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to pylons-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-devel.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: question about design decision on pyramid's core

[Michael Merickel]

None of those are public APIs so it probably just wasn't a big concern.
Pyramid's source in general is entirely flat aside from the config
subpackage. Scaffolds and scripts are things you would never import in your
own code.


On Wed, Mar 27, 2013 at 12:44 PM, Jonathan Vanasco jonat...@findmeon.comwrote:

 looking at the source, I see:

 * pyramid/chamelon_text.py
 * pyramid/chamelon_zpt.py
 * pyramid/mako_templating.py

 was there any reason for these being on the top-level, and not under a
 consolidated namespace like pyramid/templating  , or did this just
 happen randomly ?

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to pylons-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-devel?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: how are the pyramid docs managed ?

[Michael Merickel]

We are limited by what readthedocs is actually capable of doing. It doesn't
support branch aliases right now, so unless we make a stable branch that
we merge with 1.4-branch every time we update, we make do with latest.
Same issue with the major.minor -branch issue.

If someone wants to add alias support to RTD, knock yourself out!


On Fri, Feb 8, 2013 at 11:52 AM, Tshepang Lekhonkhobe tshep...@gmail.comwrote:

 On Fri, Feb 8, 2013 at 7:29 PM, Michael Merickel mmeri...@gmail.com
 wrote:
  The URL format is /major.minor-branch, with 1.4 as /latest the latest
  stable, and /master as master (in development).

 * I find this misleading. I would expect latest or dev to refer to
 master, and 1.4 (latest stable release) be referred to as stable.
 * I also find the -branch thing ugly; Can't we just call it
 major.minor?

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to pylons-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-devel?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Suggestion for Request namespace provisioning

[Michael Merickel]

On Tue, Oct 30, 2012 at 3:34 PM, Jonathan Vanasco jonat...@findmeon.com wrote:
 That pattern / functionality is great.  I'm just talking about
 proactively saying this name space is reserved for plugins, this
 namespace for projects - you can rest assured that as Pyramid grows
 and new functionality is added, you will not be affected as long as
 you stay within that container.  Right now, request.foo is a bit of a
 lottery -- from my perspective, chances are you won't add anything to
 Pyramid over there, but its not an explicit/futureproof property.

I think it's cool that Pyramid provides a way to do it, but I don't
think layering that opinion on top belongs in the core.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: Documentation Suggestions for Subscribers or Debug

[Michael Merickel]

What? Pyramid doesn't have a debug code path, minus emitting some
log messages. Do you mean that the debugtoolbar is doing something to
the response?

On Tue, May 15, 2012 at 5:57 PM, Jonathan Vanasco jonat...@findmeon.com wrote:
 I ran into an issue a few months ago regarding a NewResponse
 subscriber and failing to catch errors (
 https://groups.google.com/group/pylons-discuss/browse_thread/thread/54b5b3eb5e2ccfe/4e9a2abc09b9651f
 )

 As I prepare for a production release , my old code ( which i forgot
 to remove ) started firing -- and I finally figured out what was
 happening.

 Because I had debugging turned on via 'development.ini', Pyramid was
 catching the error  response object from the app, and replacing it
 with its own.

 In a perfect world, the Pyramid debug system would let the original
 response/request stuff somehow persist -- so code can be written that
 works on production and development.

 In a less perfect, though perfectly acceptable world, it would be
 great if the debug  event subscriber docs cross-referenced one
 another with an alert/note box that simply states that the debug
 system will 'overtake' the response object when turned on, and
 subscribers that are designed to handle errors may not work as desired
 when debugging is enabled.

 --
 You received this message because you are subscribed to the Google Groups 
 pylons-devel group.
 To post to this group, send email to pylons-devel@googlegroups.com.
 To unsubscribe from this group, send email to 
 pylons-devel+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/pylons-devel?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: Authentication - How to adapt to Single Sign On Environment (siteminder)

[Michael Merickel]

This would be done in unauthenticated_userid of a custom authentication
policy. You just need to follow the interface described here:

http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/security.html#creating-your-own-authentication-policy

On a side note, your apache plugin should be using environ['REMOTE_USER'].
Using a custom http header could be dangerous, although hopefully the
plugin would remove the header before setting its own.

On Tue, Feb 7, 2012 at 5:41 AM, Sascha Boch sascha.b...@gmx.de wrote:

 Dear group,

 I am working on an application that will be used in an environment
 that uses a 3rd party product for authentication of all web
 applications. Therefore I need to make my pyramid app accept the sign-
 on credential from the Siteminder webagent. The webagent is a plug-in
 for Apache that intercepts all interactions with the webserver. When a
 user browser logs in on a separate page and submits a valid secure
 Siteminder cookie (maintained by siteminder) the webagent will create
 a customer http header that the user never sees but the webserver
 does. The variable name is HTTP_SSE_USER. This header variable
 contains the logon user ID of the user.

 What is the smartest way of setting up my pyramid app so that the user
 is acknowledged as logged in through siteminder? I guess I need to
 check for the HTTP_SSE_USER variable somewhere. But where exactly
 could this be done?

 Thanks in advance,
 Sascha

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To post to this group, send email to pylons-devel@googlegroups.com.
 To unsubscribe from this group, send email to
 pylons-devel+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/pylons-devel?hl=en.



-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: howto access session from jinja2

[Michael Merickel]

Sorry, is this a question about jinja2? If so there's another mailing list
for that.

If you are asking about pyramid_jinja2, for use in conjunction with pyramid
then the request is already exposed in the template, so you can simply do
request.session['mykey'] to deal with the session.

On Wed, Nov 30, 2011 at 5:58 AM, Evan appli...@gmail.com wrote:

 hi group,

  i'm using pyramid and jinja2 together, and i have trouble to access
 the session data from jinja2,
  after some digging, i found this solution,

 http://stackoverflow.com/questions/2554174/how-do-i-access-session-data-in-jinja2-templates-bottle-framework-on-app-engine

  but i'm not sure about whether this is the proper way to do, by this
 way i need to get the env when setup,
  then add a 'session' key to jinja2's global vars when get a request,
  i think it means i need to do it in every view.

  is there a better way to access the 'session' data from jinja2?

 Thanks,
 Evan

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To post to this group, send email to pylons-devel@googlegroups.com.
 To unsubscribe from this group, send email to
 pylons-devel+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/pylons-devel?hl=en.



-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: pyramidtut

[Michael Merickel]

I'm unaware of another situation where this error shows up other than using
Python 2.5. I'd ensure that you are in fact on 2.7 before chasing other
solutions. If easy_install is pulling down the 2.5 egg then it means you're
on 2.5.

On Wed, Nov 16, 2011 at 9:00 AM, czam grossep...@googlemail.com wrote:

 On 16 Nov., 14:53, Chris McDonough chr...@plope.com wrote:
  On Wed, 2011-11-16 at 05:39 -0800, czam wrote:
   Hi list, I got a strange error starting with the wiki tutorial at
  http://docs.pylonsproject.org/projects/pyramid/dev/tutorials/wiki2/in.
 ..
   Seems to be a problem in the webob egg...
   Just 2 days before I got the tutorial working on another Win7-64bit, I
   am using Python 2.5.4 and everything is setup exactly as stated in the
   tutorial.
 
   d:\pyramid\pyramidtutScripts\paster.exe create -t
   pyramid_routesalchemy tutoria
   l
   Traceback (most recent call last):
 File d:\pyramid\pyramidtut\Scripts\paster-script.py, line 8, in
   module
   load_entry_point('pastescript==1.7.5', 'console_scripts', 'paster')
   ()
 File d:\pyramid\pyramidtut\lib\site-packages\pastescript-1.7.5-
   py2.5.egg\past
   e\script\command.py, line 104, in run
   invoke(command, command_name, options, args[1:])
 File d:\pyramid\pyramidtut\lib\site-packages\pastescript-1.7.5-
   py2.5.egg\past
   e\script\command.py, line 143, in invoke
   exit_code = runner.run(args)
 File d:\pyramid\pyramidtut\lib\site-packages\pastescript-1.7.5-
   py2.5.egg\past
   e\script\command.py, line 238, in run
   result = self.command()
 File d:\pyramid\pyramidtut\lib\site-packages\pastescript-1.7.5-
   py2.5.egg\past
   e\script\create_distro.py, line 73, in command
   self.extend_templates(templates, tmpl_name)
 File d:\pyramid\pyramidtut\lib\site-packages\pastescript-1.7.5-
   py2.5.egg\past
   e\script\create_distro.py, line 262, in extend_templates
   tmpl = entry.load()(entry.name)
 File d:\pyramid\pyramidtut\lib\site-packages\setuptools-0.6c11-
   py2.5.egg\pkg_
   resources.py, line 1954, in load
 File d:\pyramid\pyramidtut\lib\site-packages\pyramid-1.2.1-py2.5.egg
   \pyramid\
   __init__.py, line 1, in module
   from pyramid.request import Request
 File d:\pyramid\pyramidtut\lib\site-packages\pyramid-1.2.1-py2.5.egg
   \pyramid\
   request.py, line 6, in module
   from webob import BaseRequest
 File build\bdist.win32\egg\webob\__init__.py, line 1, in module
 File build\bdist.win32\egg\webob\datetime_utils.py, line 18, in
   module
 File d:\pyramid\pyramidtut\lib\site-packages\webob-1.2b2-py2.5.egg
   \webob\comp
   at.py, line 89
   return b''
^
   SyntaxError: invalid syntax
 
   d:\pyramid\pyramidtut
 
   Any ideas?
 
  WebOb 1.2 doesn't work under Python 2.5.  I'd try to use Python 2.6 or
  better for the tutorial.
 
  - C

 Chris, thanks for the quick reply! I installed python 2.7.2 and put it
 on my path (even rebooted) but unfortunately I get the same message
 again... easy_install seems to still fetch the 2.5egg of webob,
 anything else I'm missing?

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To post to this group, send email to pylons-devel@googlegroups.com.
 To unsubscribe from this group, send email to
 pylons-devel+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/pylons-devel?hl=en.




-- 

Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: Implementing custom Mako template lookup

[Michael Merickel]

You can add or override a renderer via the config.add_renderer() directive
here:
http://docs.pylonsproject.org/projects/pyramid/1.2/narr/renderers.html#adding-and-changing-renderers

Renderers have access to the request object so accessing the current
language shouldn't be an issue.

-- 

Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: How to run the paste server process as a daemon?

[Michael Merickel]

If you're using paster in production, it's usually smart to launch it via
supervisor so that it can restart the app if it crashes and generally
provide a better way to monitor the process. An example of doing this is in
the cookbook.

http://docs.pylonsproject.org/projects/pyramid_cookbook/dev/deployment/nginx.html#step-4-managing-your-paster-processes-with-supervisord-optional

If you just want to launch paster in daemon mode, do what Joe said and
paster serve --daemon development.ini.


-- 

Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: JSON-RPC support

[Michael Merickel]

Just as a followup, I thought I'd mention that we released pyramid_rpc 0.3
last week which revamped the API completely. When using add_jsonrpc_endpoint
you can specify a factory which will be used for security. That factory can
then set the ``__acl__`` based on the ``request.rpc_method`` property, and
your jsonrpc_method setup can specify a permission which is then validated
via the ``__acl__``.

-- 

Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: Instance level authorization in Pyramid

[Michael Merickel]

Brian, I just want to clarify some points from your original email.

Specifying the ``factory`` on the route is telling the traversal system how
to get the root of your resource tree for that specific route. Thus in your
example you might do:

def PageFactory(request):
pagename = request.matchdict.get('page')
if pagename:
# page = query db for a Page object named 'pagename'
return page

Specifying the ``context`` parameter on the view is saying for this view to
match (be invoked), the context object must be an instance of this class (or
interface). There is a subtle caveat here when using url dispatch.
Traversal stops when the path being traversed is exhausted *OR* when a
KeyError is raised. If you are attempting in your ``PageFactory`` to load a
``Page`` and that fails, raising a KeyError, then the ``PageFactory``
instance will now be the context. ACLs will then be checked against the
``PageFactory`` object instead of your intended ``Page``. In this case you
would probably prefer a 404 instead of having your view be invoked without a
valid ``Page``. Thus, if your view specifies ``route_name='foo'`` *and*
``context=Page``, then you can be sure that view will only be called if the
context is a ``Page``. On top of that if you specify a permission, then the
view is only invoked if that permission was in the ACL as well.

-- 

Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: Instance level authorization in Pyramid

[Michael Merickel]

It's not incorrect, I just merged two thoughts which probably made it
unclear. If he doesn't specify a ``traverse`` parameter then traversal will
not happen, which will use a similar RootFactory to what I showed except
that he might want to raise a HTTPNotFound if the ``page`` is None. The rest
of the stuff was about traversal, which I probably should've kept my mouth
shut about. ;-)

-- 

Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: Invoking a class method using json rpc

[Michael Merickel]

The JSONRpcViewMapper was never supported for classes. However in
pyramid_rpc 0.3 which was released last week it ships with a default view
mapper that works well with classes, as well as a whole new API for defining
the views that allows other things such as permissions.

-- 

Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Improving URL Dispatch

[Michael Merickel]

Hey people, I've been looking into ways to resolve some of the most common
complaints with URL Dispatch. The few that I have seen more than once in the
past are:

1) I have a lot of placeholders in this URL, generating it is a pain and I'd
like to supply some defaults so that when using route_url I don't have to
send it *everything*.

This is already possible by supplying a pregenerator to your route, however
I've created a pre-baked DefaultsPregenerator for this purpose and thrown it
into the add_route API to service: config.add_route('foo', '/bar/{baz}',
defaults={'baz': 5}). Is this common enough that it warrants the extra API
in add_route?

2) I'm using pyramid_handlers or pyramid routes/views and it's a pain to
have to specify different route names for logically similar patterns. For
example, using handlers:

config.add_handler('users_index', '/users', handler=UserHandler,
action='index')
config.add_handler('users', '/users/{action}', handler=UserHandler)

When generating URLs for this handler, you need to remember that if you want
the 'index' action, it's users_index, and for everything else it's
users.

I've implemented a RouteGroup concept here:
https://github.com/Pylons/pyramid/blob/feature.dispatch-defaults/pyramid/urldispatch.py#L47
The idea is that you can group patterns, and (similar to the Pylons-style
Routes package) it will attempt to determine which pattern you wanted to use
for a particular set of placeholders. This particular branch keeps it pretty
sane and does the matching by only looking at the set of supplied parameters
to route_url and finding the matching route with the largest number of
placeholders. Integrating something like this into Pyramid depends on what
use-cases we are trying to solve.

3) Dispatch isn't as extensible as traversal. This will always be the case,
but we've created a branch that enhances config.include('some_package',
route_prefix='/users') to enhance the relativity of routes by mounting a
package at a particular prefix.

I'm basically searching for opinions on the topics to judge whether they are
useful to have in Pyramid. Obviously a major goal of these features is that
there is no performance impact if you choose to not use them. The current
dispatch is raw, but it works and it's pretty general, so I was looking at
ways to add some convenience APIs to help people out with common dispatch
use-cases.

Thanks for your ideas, and hopefully this isn't just bike shedding. :-)


-- 

Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: Pyramid authentication options

[Michael Merickel]

 The velruse.yaml config, minus the private keys (which is why it's not
 source controlled) looks like this:


Probably obvious, but you might want to go ahead and version control an
example yaml file with placeholders for the keys.

-- 

Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: [Paste] [WebError] where are the docs/source and who's maintaining now?

[Michael Merickel]

WebError's codebase was moved to the Pylons Project's github account.

https://github.com/Pylons/weberror

AFAIK Ben is still the active maintainer.

Michael


On Tue, Apr 12, 2011 at 4:10 AM, Chris Withers ch...@simplistix.co.ukwrote:

 Hi All,

 Is https://bitbucket.org/bbangert/weberror WebError's home now?
 Are there any docs anywhere?
 Who's the current active maintainer?

 Oh, and which is the correct mailing list for WebError?
 (I'll send the questions I have just to paste-users until told
 otherwise...)

 cheers,

 Chris

 --
 Simplistix - Content Management, Batch Processing  Python Consulting
   - http://www.simplistix.co.uk

 --
 You received this message because you are subscribed to the Google Groups
 Paste Users group.
 To post to this group, send email to paste-us...@googlegroups.com.
 To unsubscribe from this group, send email to
 paste-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/paste-users?hl=en.



-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: What's the best way to optimize database connections in Pyramid?

[Michael Merickel]

I've been a fan of tacking the connection onto the request object using
@reify, thus if your request never calls request.db it doesn't have any db
overhead.

Thanks to reify, it reuses the same connection throughout that request. If
you want to ensure that the connection is closed at the end of the request,
you can also add a finished_callback to handle that.

class MyRequest(Request):
@reify
def db(self):
# do stuff to get connection either from middleware in previous
email
# or actually create a connection
conn =

# optional: add callback to cleanup after request is complete
def _cleanup(request):
conn.close()
self.add_finished_callback(_cleanup)
return conn

The cleanup and things is handled by repoze.tm2 if using something like
SQLAlchemy with the ZopeTransactionExtension, but otherwise you'll probably
want to handle it yourself.


Michael


On Sun, Mar 13, 2011 at 8:54 AM, Fernando Correa Neto fcd...@gmail.comwrote:

 Hi

 On Sun, Mar 13, 2011 at 5:54 AM, Seth seedifferen...@gmail.com wrote:
 [snip]
  How are other people connecting to a db with high-traffic sites using
  Pyramid and avoiding the static_route re-connection nonsense? Perhaps we
  could request to get a matched_route object on the NewRequest event
 object?

 I usually try to stick to a connection that is always on environ.
 You'd have a wsgi middleware that always try to get the connection
 from the threadinglocal and expose that under some environ key, say,
 'conn.mongo'.
 If the middleware fails to get that from the thread, you'd create
 another connection and then re-expose it under the same key.

 Regards,
 Fernando

 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To post to this group, send email to pylons-devel@googlegroups.com.
 To unsubscribe from this group, send email to
 pylons-devel+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/pylons-devel?hl=en.



-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: Setting cookies in Pyramid for @action()s or HTTPFound redirects?

[Michael Merickel]

Going through the trouble of creating a webob response is much more
complicated than simply adding a response_callback.

def _set_cookie(request, response):
response.set_cookie()
request.add_response_callback(_set_cookie)

Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: Help with creating view functions

[Michael Merickel]

What is the exact error?

I noticed you're using @view_config on the blog_view that isn't working,
with only a renderer argument. This makes me think that you might believe
that code will do the same as render_to_response(..) in your pages_view.

In fact, @view_config is a different way of doing config.add_view that
requires you to use config.scan(). I'd suggest doing a little bit more
reading on the difference between config.add_view() and @view_config
because they both accomplish the same thing and aren't intended to be used
together on the same view.

Michael


On Sat, Mar 12, 2011 at 7:09 AM, AwaisMuzaffar awais1...@googlemail.comwrote:

 Hi Guys,

 I have the following code for the view:

 def pages_view(request):
path = request.path.split('/')[1]
dbsession = DBSession()
page = dbsession.query(PagesTable).from_statement(
'SELECT * FROM pages WHERE
 path=:page_path').params(page_path=path).first()
pages_dir = os.getcwd() + '/myblog/templates/pages/'
one = 'hello'
if page:
if path == '':
 return render_to_response('myblog:templates/pages/
 home.mak',
{'page':page, 'one':one}, request=request)
elif os.path.isfile(pages_dir + path + '.mak'):
return render_to_response('myblog:templates/pages/
 %s.mak'%path,
{'page':page}, request=request)
else:
return render_to_response('myblog:templates/pages/
 index.mak',
{'page':page}, request=request)
raise NotFound()

 Basically, it checks if a page exists in the table. If it does it
 renders a template according to the path name, or if there is no such
 template it just renders a default template.

 The next part I want to do is create a seperate view function for my
 'blog' page, with some logic for this page.

 I've tried the following example, but it throws an undefined error
 when when I load the page:

 @view_config(renderer='myblog:templates/pages/my-blog.mak')
 def blog_view(request):
one = 'Hello World'
return {'one':one}

 I do apologise for such basic questions. Any insight given will be
 greatly appreciated.

 Kind Regards,
 Awais M.



 --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To post to this group, send email to pylons-devel@googlegroups.com.
 To unsubscribe from this group, send email to
 pylons-devel+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/pylons-devel?hl=en.



-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: computing url for view registered by name

[Michael Merickel]

By leaving out the context you are effectively registering those views to
*any* context, which is almost always undesirable.

Regardless, my previous reply remains correct, if you want the path hanging
off of /, simply use resource_url(request.root, request) and
resource_url(request.root, request, 'history').

request.root is the root context, thus the context used for views hanging
off of /.

Michael


On Fri, Mar 4, 2011 at 12:56 PM, Chris Withers ch...@simplistix.co.ukwrote:

 On 02/03/2011 00:48, Michael Merickel wrote:

 I noticed in your example you aren't specifying a context= or for_= in
 the view_config, implying you maybe intended to use route_name instead
 of name with url dispatch.


 Nope, no routes here, these are just views hanging off /, not registered
 against any context...


 cheers,

 Chris

 --
 Simplistix - Content Management, Batch Processing  Python Consulting
   - http://www.simplistix.co.uk


-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: computing url for view registered by name

[Michael Merickel]

I noticed in your example you aren't specifying a context= or for_= in the
view_config, implying you maybe intended to use route_name instead of name
with url dispatch.

If you are using traversal your application basically assumes a resource
tree, and so to get the url you provide a resource object that defines
__name__ and __parent__. The URL is then generated based on that resource's
location in the tree... the actual name of the view on that resource is
computed using the *elements on resource_url(). In the case of not defining
a context, you probably mean the root context object (although it could be
attached anywhere since you didn't specify). Assuming you wanted the root
context, you could do

resource_url(request.root, request)
and
resource_url(request.root, request, 'history')

HTH,
Michael

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: default permission overriding

[Michael Merickel]

For the record, I mentioned that constant in the interfaces.py the other day
and Chris didn't realize it was there... it's also undocumented. He went so
far as to suggest removing it.

If there's going to be a constant anywhere, I'd imagine it should be in
pyramid.security.

Michael


On Tue, Feb 22, 2011 at 7:33 PM, Daniel Holth dho...@gmail.com wrote:

 There is a constant. It is called pyramid.interfaces.NO_PERMISSION_REQUIRED
 ; however, the string is documented. This probably makes the documentation
 shorter because you would have to use the string if you are configuring with
 ZCML.

 This is /only/ required at all when you need your application to have a
 default permission and be secure by default.

 If you have a great need to create unsecured views with the greatest of
 convenience, you can simply leave the default permission feature turned off.



  --
 You received this message because you are subscribed to the Google Groups
 pylons-devel group.
 To post to this group, send email to pylons-devel@googlegroups.com.
 To unsubscribe from this group, send email to
 pylons-devel+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/pylons-devel?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.