Project definition files¶

Sharing events with providers¶

Event sharing allows applications to send telemetry events back to application package owners. When testing an application with an application package requiring event sharing, you must explicitly enable event sharing for the application installation to succeed.

To enable sharing of specific events, you must also have the events configured in the configuration.telemetry_event_definitions section in the manifest.yml file for the application package. You must also have the MANAGE EVENT SHARING global privilege to authorize event sharing for the application.

After event sharing is enabled in your application’s manifest, you must add a telemetry section to your snowflake.yml file that specifies the events you want to share from your application. The following code shows a sample telemetry section:

definition_version: 2
entities:
  app:
    type: application
    from:
      target: pkg
    telemetry:
      share_mandatory_events: true
      optional_shared_events:
        - DEBUG_LOGS

...

The following examples illustrate different ways to share events in the snowflake.yml file. All of the examples are based on the following section in the application package’s manifest.yml file:

configuration:
    telemetry_event_definitions:
        - type: ERRORS_AND_WARNINGS
          sharing: MANDATORY
        - type: DEBUG_LOGS
          sharing: OPTIONAL

• Authorize telemetry and share all mandatory events with the provider. In this case, only ERRORS_AND_WARNINGS events are shared.

  definition_version: 2
  entities:
    app:
      type: application
      from:
        target: pkg
      telemetry:
        share_mandatory_events: true
  

  Copy

• Share both DEBUG_LOGS and ERRORS_AND_WARNINGS events with the application package provider. Setting share_mandatory_events to true enables sharing of mandatory ERRORS_AND_WARNINGS events, while the optional_shared_events section enables optional events like DEBUG_LOGS.

  definition_version: 2
  entities:
    app:
      type: application
      from:
        target: pkg
      telemetry:
        share_mandatory_events: true
        optional_shared_events:
          - DEBUG_LOGS
  

  Copy

Snowpark processor¶

One of the processors supported by Snowflake CLI is snowpark, which applies Snowpark annotation processing to Python files. The following shows the basic structure and syntax for different processing environments:

• To execute code in a conda environment, use the following:

  pkg:
    artifacts:
      - src: <some_src>
        dest: <some_dest>
        processors:
            - name: snowpark
              properties:
                env:
                  type: conda
                  name: <conda_name>
  

  Copy

  where <conda_name> is the name of the conda environment containing the Python interpreter and the Snowpark library you want to use for Snowpark annotation processing.

• To execute code in a Python virtual environment, use the following:

  pkg:
    artifacts:
      - src: <some_src>
        dest: <some_dest>
        processors:
            - name: snowpark
              properties:
                env:
                  type: venv
                  path: <venv_path>
  

  Copy

  where <venv_path> is the path of the Python virtual environment containing the Python interpreter and the Snowpark library you want to use for Snowpark annotation processing. The path can be absolute or relative to the project directory.

• To execute code in the currently active environment, use any of the following equivalent definitions:

  pkg:
    artifacts:
      - src: <some_src>
        dest: <some_dest>
        processors:
            - name: snowpark
              properties:
                env:
                  type: current
  

  Copy

  or

  pkg:
    artifacts:
      - src: <some_src>
        dest: <some_dest>
        processors:
            - name: snowpark
  

  Copy

  or

  pkg:
    artifacts:
      - src: <some_src>
        dest: <some_dest>
        processors:
            - snowpark
  

  Copy

For more information about custom processing, see Automatic SQL code generation and the snow app bundle command.

Templates processor¶

Snowflake Native App projects support templates in arbitrary files, which lets you expand templates in all files in an artifact’s src directory. You can enable this feature by including a templates processor in the desired artifacts definition, as shown in the following example:

definition_version: 2
entities:
  pkg:
    type: application package
    identifier: myapp_pkg
    artifacts:
      - src: app/*
        dest: ./
        processors:
          - templates
    manifest: app/manifest.yml
  app:
    type: application
    identifier: myapp_<% fn.get_username() %>
    from:
      target: pkg

When Snowflake CLI uploads the files to a stage, it automatically expands the templates before uploading them. For example, suppose your application contained an app/README.md file with the following content that includes the <% ctx.entities.pkg.identifier %> template:

This is a README file for application package <% ctx.entities.pkg.identifier %>.

The template is then expanded to the following before uploading the file to a stage:

This is a README file for application package myapp_pkg.

Limitations¶

Currently, Snowflake CLI does not support

• Multiple override files.

• A blank override file. Only create this file if you want to override a value from snowflake.yml.