Skip to content
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

include complete filename of invoking frame #280

Open
sqlalchemy-bot opened this issue Oct 2, 2018 · 12 comments
Open

include complete filename of invoking frame #280

sqlalchemy-bot opened this issue Oct 2, 2018 · 12 comments
Labels
bug Something isn't working low priority

Comments

@sqlalchemy-bot
Copy link

Migrated issue, originally created by Mario Frasca (@mfrasca)

I'm distributing templates with resources. they go next to each other. my python program reads the template using a lookup, and it's the template that should be able to open the resource and include it in the rendering process.

in practice? it's postscript, and the resource is an image which I want to include in the result.

the problem is that once the template file has been copied where mako can find it thanks to the lookup, I don't know how to get to the location and open the resource, located relative to it.

it would not be such a big deal, if mako did not strip the complete path of source files in the frames information.

this is the invoked frame, where I need to know the location of the template file:
(frame=<frame object at 0x7f4f607fd6b8>, filename='/home/mario/.virtualenvs/ghide-3.1-dev/lib/python3.5/site-packages/ghini.desktop-3.1.8-py3.5.egg/bauble/plugins/report/utils.py', lineno=375, function='add_text', code_context=[' print(inspect.getouterframes(inspect.currentframe()))\n'], index=0)

please notice the complete path of filename

this is the invoking frame, where most information is missing:

(frame=<frame object at 0x7f4f60218908>, filename='accession_label_single_qr_ps_mako', lineno=103, function='render_body', code_context=None, index=None)

the above is what I can read using inspect.getouterframes(inspect.currentframe()), but precisely the same you can also get with sys._getframe().f_back.co_filename

@sqlalchemy-bot
Copy link
Author

Changes by Mario Frasca (@mfrasca):

  • edited description

@sqlalchemy-bot
Copy link
Author

Michael Bayer (@zzzeek) wrote:

hi there -

I don't understand what you're trying to do. are you trying to retrieve information from inside of sys._current_frames() ? I don't have any knowledge on how to impact what is reported inside of frames, and also trying to inspect tracebacks for purposes other than debugging is probably a bad idea and certainly not what one would expect from a template language.

@sqlalchemy-bot
Copy link
Author

Mario Frasca (@mfrasca) wrote:

I want to know the location of the template being rendered, because my resources are next to it.

@sqlalchemy-bot
Copy link
Author

Michael Bayer (@zzzeek) wrote:

I know of no way to help you with that, sorry.

@sqlalchemy-bot
Copy link
Author

Mario Frasca (@mfrasca) wrote:

I suppose mako is creating the frames, and mako's frames are very incomplete and where they hold information, it's incorrect. in the whole outerframes, all filename fields have a complete absolute path, except the ones relative to mako. lineno is incorrect. function is always render_body, and code_context and index are both None. I guess this is also a source of problems when errors are met in templates, because you're not able to indicate neither where the error happened, nor what code to look for.

@sqlalchemy-bot
Copy link
Author

Mario Frasca (@mfrasca) wrote:

I'll have a look, this is biting from two sides, and actually the wrong information in exceptions is more serious, from my point of view.

@sqlalchemy-bot
Copy link
Author

Michael Bayer (@zzzeek) wrote:

oh. Well, Mako is not an interpreter, it compiles to a Python module, and Python runs the code. A stackframe is at best going to give you the Python module that's running. This is not the "wrong" information, this is exactly what's running, it's just not in terms of the source template that was used to generate the module. To format exceptions in terms of the source template file, there is a conversion you use which is documented here: http://docs.makotemplates.org/en/latest/usage.html#handling-exceptions . This makes use of the RichTraceback object here: https://github.com/zzzeek/mako/blob/master/mako/exceptions.py#L71 so you probably want to look at what that's doing.

@sqlalchemy-bot
Copy link
Author

Mario Frasca (@mfrasca) wrote:

YES, that was it, thank you!

        import mako.template
        import sys
        here = sys._getframe()
        caller = here.f_back
        template_name = caller.f_code.co_filename
        info = mako.template._get_module_info(template_name)
        print(info.template_filename)

@sqlalchemy-bot
Copy link
Author

Mario Frasca (@mfrasca) wrote:

you see, Jinja2 puts the complete name in the frame, just like the python-python frames.
I have to do the following for mako:

    import sys
    import os.path
    here = sys._getframe()
    # Mako names it 'render_body', Jinja2 'block_body'
    while here.f_code.co_name not in ['render_body', 'block_body']:
        here = here.f_back
    template_name = here.f_code.co_filename
    if here.f_code.co_name == 'block_body':
        # Jinja2 puts the complete name in the frame
        return os.path.dirname(template_name)
    else:
        # this is needed and works for Mako templates
        import mako.template
        info = mako.template._get_module_info(template_name)
        return os.path.dirname(info.template_filename)

@sqlalchemy-bot
Copy link
Author

Michael Bayer (@zzzeek) wrote:

yes, Armin Ronacher added that to jinja2 a long time ago using some extremely deep voodoo that I had asked him to help me to adapt to Mako, but it never happened. Some years later I probably tried to look and see what he did but it was extremely complicated. I have no resources to implement such a feature in Mako. As a project, Mako is not really maintained anymore beyond keeping the current featureset running well.

@sqlalchemy-bot
Copy link
Author

Mario Frasca (@mfrasca) wrote:

having a workaround, I don't consider it 'major' any more.

@sqlalchemy-bot
Copy link
Author

Changes by Mario Frasca (@mfrasca):

  • added labels: low priority

@sqlalchemy-bot sqlalchemy-bot added low priority bug Something isn't working labels Nov 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working low priority
Projects
None yet
Development

No branches or pull requests

1 participant