Pyramid status update...

[Chris McDonough]

Hi folks,

Since the last status update I gave maybe a month or so ago, where I
enumerated the list of "must-haves" for a 1.0beta Pyramid release (see
<http://groups.google.com/group/pylons-devel/browse_thread/thread/c0d56e164886c253/5f880003fbd18797>), we've had two more alpha releases (1.0a8 and 1.0a9) that more or less killed the "must-have" and "should-have" items listed in that status report. The changes made in those releases can be seen here: http://docs.pylonshq.com/pyramid/dev/changes.html

New niggly things keep popping up and replacing the issues we swat down,
of course.

Here's the current "must-have" punchlist:

Must-Have (before 1.0)
----------------------

- Write a "Whats New" (delta from BFG 1.3)

- API docs for ``pyramid.views.action``. (also, @action decorator
uses ``name`` for the method name; consider whether this will be
confused with ``name`` of ``view_config`` which means something
else)

- Add docs for ``__action_decorator__`` attr of handler.

- Use a commit veto when configuring repoze.tm2 in paster templates
for non-1X, 2X, or 3X responses.

- Figure out how to slim the herd of paster templates. Related:
https://github.com/Pylons/pyramid/issues#issue/40,
https://github.com/Pylons/pyramid/issues#issue/42,
https://github.com/Pylons/pyramid/issues#issue/44,
https://github.com/Pylons/pyramid/issues#issue/94 ,
https://github.com/Pylons/pyramid/issues#issue/95

- Explain how to use i18n localization in Mako and Jinja2.

- Turn Forbidden status code into a 403 (it's currently a 401, which
is for bw compat, but is misleading).

- Fix too-long template lines in tutorials for PDF renderings.

- Bug in URL dispatch pattern matching:
https://github.com/Pylons/pyramid/issues#issue/90

- Allow ``pyramid.security.remember`` to accept a list of tokens for
use when there's an ``auth_tkt`` authentication policy:
https://github.com/Pylons/pyramid/issues#issue/81 and
https://github.com/Pylons/pyramid/issues#issue/78

- Add docs for ``route_path`` and ``route_url``, etc to Request API
docs (see also https://github.com/Pylons/pyramid/issues#issue/19).

By far, the hardest task on this list is "slim down the herd of paster
templates". The idea behind this is to have Pyramid ship with fewer
paster templates (ideally just one single example template), and depend
on third-party paster templates shipped in external packages which have
their own release cycles and "opinions", so we don't need to maintain
and document as many templates (and their attendant contexts and
opinions) within the core.

I'd like to be able to freeze feature development on the Pyramid trunk
in preparation (and perhaps a docs printing) for a first beta by the end
of January. We'll see how it goes.

- C

[Raviteja]

Hi Chris,

We are a team, who started working on a web-application using pyramid. Pyramid is very-well documented, and so we decided to develop using it, even if it's in alpha. We are very excited by the releases of the pyramid framework, and we wanted to be up-to-date so that we don't miss any developments/bugs. When can we expect the beta release of the framework ? Are you adding any new features at present?

Thanks,

Teja

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

[Chris McDonough]

As the end of that message says, we'd like to have a beta out by the end
of January. But that's a goal, not really a promise.

- C

> +unsub...@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...@googlegroups.com.
> To unsubscribe from this group, send email to pylons-devel

> +unsub...@googlegroups.com.

[Chris McDonough]

On Wed, 2011-01-12 at 11:26 +0100, Christoph Zwerschke wrote:

> Am 12.01.2011 10:03, schrieb Chris McDonough:
> > - Figure out how to slim the herd of paster templates.
>

> You can use http://pythonpaste.org/tempita/ to make case distinctions in
> the paster templates, so you don't need to create separate templates for
> every subfeature or option that involves only minor tweaks. TurboGears
> is doing it that way and it works very well, the templates do not get
> too complicated.

I'm not a big fan of conditionalized templates, as they're even harder
to test than non-conditionalized ones (we don't even yet have automated
tests for the non-conditionalized ones).

- C

[Chris McDonough]

On Wed, 2011-01-12 at 11:56 +0100, Christoph Zwerschke wrote:

> Am 12.01.2011 11:30, schrieb Chris McDonough:
> > I'm not a big fan of conditionalized templates, as they're even harder
> > to test than non-conditionalized ones (we don't even yet have automated
> > tests for the non-conditionalized ones).
>

> As these would be integration or system tests anyway, I don't see how
> these tests would be fundamentally different. I would simply create the
> project in a temp dir with paster quickstart and different combination
> of options, and then run the functional tests of the created project.

The intent is to have only one non-conditional paster template in the
core distribution, but this work might be useful to other paster
template developers.

> Will check how this works if I find some time this weekend.
>
> -- Christoph
>

[Christoph Zwerschke]

Am 12.01.2011 12:02, schrieb Chris McDonough:
> The intent is to have only one non-conditional paster template in the
> core distribution, but this work might be useful to other paster
> template developers.

Ok, maybe these templates could go into a supplementary package then.
TurboGears 2 has them in a separate package, too (tg2dev instead of
tg2). The core package would then keep only the "core" templates.

-- Christoph

[Jeff Madynski]

Chris,
I can possibly provide pyramid-jinja2 i18n docs, but I am not sure if
I've taken a decent approach.

I started following the project a few weeks ago. I like it. While
reading through the docs, I was playing along by modifying shootout
(https://github.com/jeffmad/shootout). I changed it to use jinja2,
repoze.who 2.0, and beaker, also changed some things to look like
1.0a9. It was fun to learn things by changing them.

Then I thought it would be interesting to try to make a spanish version.
I followed along on
http://docs.pylonshq.com/pyramid/dev/narr/i18n.html and
http://jinja.pocoo.org/extensions/

For jinja2, in addition to pyramid instructions for i18n, I added
1) a message extractor in setup.py ('**.jinja2',
'jinja2.ext:babel_extract', None)
2) enable jinja2 i18extension in development.ini (below)
3) put {%trans %} tags in the templates.

Then after i had everything in place and went to test, I got stuck.
It did not work. Appending _LOCALE_=es was not doing anything. After
poking around quite a bit adding logging in pyramid/i18n.py and
pyramid_jinja/__init__.py, I figured out that the Translations object
I was passing to jinja2 had domain=messages, so nothing got
translated in jinja2. I am still not sure why fallback didn't work.

In any case, I ended up getting it working by
env.install_gettext_callables() in Jinja2TemplateRenderer __call__
(below). Since jinja2 doesn't pass the domain in, this patch sets it
to "shootout"

I am not really comfortable with this since changing the environment
on every request seems wrong and I don't understand what concurrency
problems may be lurking.

Another approach might be to force the domain to be listed in each
tag, but that seems ugly. On my next app, I'll be a lot more open to
chameleon since you do not have to translate strings in the py code
like you do in jinja2. Most of those translations should be moved to
the template, but I am warming up to chameleon.

I can try to condense my experience in an rst and point you to it if
you think I am on the right track. Any suggestions appreciated.

--jeff

development.ini

[app:shootout]
use = egg:shootout
jinja2.extensions = jinja2.ext.i18n

#new imports
from pyramid.i18n import get_localizer
from pyramid.i18n import get_locale_name
from pyramid.i18n import Translations
import logging

inside Jinja2TemplateRenderer

def __call__(self, value, system):
try: system.update(value)
except (TypeError, ValueError):
raise ValueError('renderer was passed non-dictionary as value')

#start i18 patch here
# TODO do this stuff only when jinja2.i18n.ext is loaded
localizer = get_localizer(system['request'])
localeName = get_locale_name(system['request'])
settings = system['request'].registry.settings
default_locale_name = settings.get('default_locale_name', 'en')
if localeName == default_locale_name:
self.environment.install_gettext_callables(localizer.translations.ugettext,
localizer.translations.ungettext, newstyle=True)
else:
# TODO cannot hardcode domain here, must get it by lookup
config or lookup in translations
def mydgettext(message):
return localizer.translations.dugettext(u'shootout', message)
def mydngettext(singular, plural, num):
return
localizer.translations.dungettext(u'shootout',singular, plural, num )
self.environment.install_gettext_callables(mydgettext,
mydngettext, newstyle=True)
# finish i18n patch here
result = self.template.render(system)
return result

Lastly, must make sure {{ gettext(msg, domain) }} works in jinja2