What does 'with context' mean when doing an import?

Question

I've been looking for an explanation in the SaltStack docs about what 'with context' means. But there's only examples of using context.

What is 'context'?

What does it do here? And why is Debian ignored in the map.jinja file? (for example map.log_dir seems to "jump down" a level)

# config.sls
{% from "bind/map.jinja" import map with context %}

include:
  - bind

{{ map.log_dir }}:
  file.directory:
    - user: root
    - group: {{ salt['pillar.get']('bind:config:group', map.group) }}
    - mode: 775
    - require:
      - pkg: bind

# map.jinja
{% set map = salt['grains.filter_by']({
    'Debian': {
        'pkgs': ['bind9', 'bind9utils', 'dnssec-tools'],
        'service': 'bind9',
        'config_source_dir': 'bind/files/debian',
        'zones_source_dir': 'zones',
        'config': '/etc/bind/named.conf',
        'local_config': '/etc/bind/named.conf.local',
        'key_config': '/etc/bind/named.conf.key',
        'options_config': '/etc/bind/named.conf.options',
        'default_config': '/etc/default/bind9',
        'default_zones_config': '/etc/bind/named.conf.default-zones',
        'named_directory': '/var/cache/bind/zones',
        'log_dir': '/var/log/bind9',
        'user': 'root',
        'group': 'bind',
        'mode': '644'
    },
    'RedHat': {
        'pkgs': ['bind'],
        'service': 'named',
        'config_source_dir': 'bind/files/redhat',
        'zones_source_dir': 'zones',
        'config': '/etc/named.conf',
        'local_config': '/etc/named.conf.local',
        'default_config': '/etc/sysconfig/named',
        'named_directory': '/var/named/data',
        'log_dir': '/var/log/named',
        'user': 'root',
        'group': 'named',
        'mode': '640'
    },

Answer 1

Since this page is the top search result for "jinja import with context" (and the other answer doesn't actually say what it does), and I keep coming back to this page every couple of months when I need to mess with Salt but forget what with context does:

When you import foo in jinja, normally the macros you've defined in foo don't have access to variables in the file you're importing it from. As an optimization, Jinja will then cache this if you import again later in the file. If instead you do import foo with context, then the macros in foo can access the variables in the file it's being imported from. The trade-off is that Jinja no longer caches foo, so you pay in render time.

When you do include, your variables do get passed into the other file. You then render the contents of the other file and paste them in. If you do include foo without context, you don't pass the variables of the current file in. This is useful, because Jinja will optimize this by caching the contents of foo, speeding up your render.

Answer 2

with context is part of the jinja template engine.

You can read more about it in the jinja docs:

• import context behavior
• context API

Regarding the missing debian data - is this your complete map.jinja? the snippet misses }, default='Debian') %} according to grains.filter_by