New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Render Mako template errors for template debugging #367

Closed
sqlalchemy-bot opened this Issue Apr 7, 2016 · 5 comments

Comments

Projects
None yet
1 participant
@sqlalchemy-bot

sqlalchemy-bot commented Apr 7, 2016

Migrated issue, originally created by n1ywb (@n1ywb)

Ran alembic init --template multidb alembic

(note my use of multidb template)

Then trying to run alembic revision -m 'test'

Getting TypeError: expected string or buffer

Of course that's being thrown from inside the compiled mako template so the backtrace isn't useful.

At /home/jeff/repos/alembic/alembic/util/pyfiles.py:15

template.render_unicode should be called in a try/except block a la http://docs.makotemplates.org/en/latest/usage.html#handling-exceptions

    try:
        f.write(
            template.render_unicode(**kw).encode(output_encoding)
        )
    except:
        print exceptions.text_error_template().render()
        raise

Then you get a useful backtrace like

  File "alembic/script.py.mako", line 36, in render_body
    % for db_name in re.split(r',\s*', db_names):
  File "/home/jeff/.virtualenvs/wsm/lib/python2.7/re.py", line 171, in split
    return _compile(pattern, flags).split(string, maxsplit)
TypeError: expected string or buffer

The confounding factor here is that the multidb template is broken by default, but that would have been obvious immediately if the mako exception had been reported at first.

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Apr 9, 2016

Michael Bayer (@zzzeek) wrote:

The confounding factor here is that the multidb template is broken by default

It looks like you used an invalid alembic.ini file with the script that did not have the "databases" option. So I'd disagree this is broken "by default" unless you can provide more detail.

It's not an option to simply "print" a stack trace like that. It would be inconsistent vs. how all other errors are handled. Unfortunately Mako does not yet provide the option of delivering a completely normal stack trace with the data within it replaced that can be re-raised; Jinja2 has such a feature and I've asked Armin many times to please provide that as a third party package so Mako can make use of it.

So instead we have to do something like what Sphinx does, write it to a named temp file. Also, an error in a template causes it to write a blank file right now and that is a more serious issue.

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Apr 9, 2016

Michael Bayer (@zzzeek) wrote:

  • Errors which occur within the Mako render step are now intercepted
    and raised as CommandErrors like other failure cases; the Mako
    exception itself is written using template-line formatting to
    a temporary file which is named in the exception message.
    fixes #367

9b32cb7

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Apr 9, 2016

Changes by Michael Bayer (@zzzeek):

  • changed status to closed
@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Apr 10, 2016

n1ywb (@n1ywb) wrote:

As long as it's available somewhere; thanks!

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Apr 11, 2016

n1ywb (@n1ywb) wrote:

I guess I still had the old .ini file from the first time I ran alembic with the default template; I see the multidb template ini file does set databases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment