Fichiers de définition de projet¶

Un fichier de définition de projet appelé snowflake.yml déclare un répertoire comme étant un projet Snowflake Native App. Il s’agit d’un fichier contrôlé par version qui réside à la racine du répertoire d’un projet Snowflake Native App et qui peut être créé manuellement ou par Snowflake CLI dans le cadre de l’initialisation du projet. Tant que vous pouvez fournir ce fichier structuré dans le répertoire mais que vous choisissez d’utiliser votre propre structure de projet indépendante, Snowflake CLI peut découvrir les fichiers pertinents et exécuter ses fonctions comme d’habitude.

Pour les Native Apps, votre snowflake.yml ressemblerait à ce qui suit :

definition_version: 2
entities:
  pkg:
    type: application package
    identifier: <name_of_app_pkg>
    stage: app_src.stage
    manifest: app/manifest.yml
    artifacts:
      - src: app/*
        dest: ./
      - src: src/module-add/target/add-1.0-SNAPSHOT.jar
        dest: module-add/add-1.0-SNAPSHOT.jar
      - src: src/module-ui/src/*
        dest: streamlit/
    meta:
      role: <your_app_pkg_owner_role>
      warehouse: <your_app_pkg_warehouse>
      post_deploy:
        - sql_script: scripts/any-provider-setup.sql
        - sql_script: scripts/shared-content.sql
  app:
    type: application
    identifier: <name_of_app>
    from:
      target: pkg
    debug: <true|false>
    meta:
      role: <your_app_owner_role>
      warehouse: <your_app_warehouse>

Copy

Propriétés communes des entités¶

Le tableau suivant décrit les propriétés communes disponibles pour les entités de définition de projet pour les Native Apps. Voir Spécifier des entités pour plus d’informations sur les entités de définition de projet.

Propriétés communes des entités¶
Propriété	Définition
type required, string	Le type d’entité à gérer. Pour Snowflake Native App, les valeurs valides incluent : `application package`. Pour plus d’informations sur les propriétés du paquet d’application, voir Propriétés de l’entité du paquet d’application. `application`. Pour plus d’informations sur les propriétés de l’application, voir Propriétés de l’entité d’application.
identifier optional, string	Identificateur Snowflake facultatif pour l’entité, les identificateurs entre guillemets et non entre guillemets sont pris en charge. Pour utiliser des identificateurs entre guillemets, incluez les guillemets dans la valeur de YAML (par exemple, `’”My Native Application Package”’`). Si non spécifié, l’ID d’entité dans la définition du projet est utilisé comme identificateur.
meta.warehouse optional, string	L’entrepôt est utilisé pour exécuter les scripts fournis dans le cadre de `meta.post_deploy`, si des commandes SQL dans ces scripts nécessitent l’utilisation de l’entrepôt. Par défaut : entrepôt spécifié pour la connexion dans le fichier Snowflake CLI `config.toml`. Note Si vous ne spécifiez pas d’entrepôt, l’application passe la validation, mais l’installation échoue. En règle générale, vous spécifiez cette valeur dans `snowflake.local.yml`, comme décrit dans Remplacements de la définition du projet.
meta.role optional, string	Rôle à utiliser lors de la création de l’entité et des objets côté fournisseur. Note Si vous ne spécifiez pas de rôle, Snowflake CLI tente d’utiliser le rôle par défaut attribué à votre utilisateur dans votre compte Snowflake. En règle générale, vous spécifiez cette valeur dans `snowflake.local.yml`, comme décrit dans Remplacements de la définition du projet. Par défaut : rôle spécifié dans la Connexion Snowflake CLI
meta.post_deploy optional, sequence	Liste de scripts SQL à exécuter après la création de l’entité. L’exemple suivant montre comment définir ces scripts dans le fichier de définition de projet : definition_version: 2 entities: myapp_pkg: type: application package ... meta: post_deploy: - sql_script: scripts/post_deploy1.sql - sql_script: scripts/post_deploy2.sql Copy Ces scripts sont appelés par des commandes qui créent ou mettent à jour une entité. Par exemple, en exécutant la commande `snow app deploy`, elle exécute ces scripts après la création ou la mise à jour d’un paquet. Ils sont également exécutés par `snow app run` si l’instance d’application n’est pas directement installée à partir d’une directive de version ou de publication. Vous pouvez également utiliser des modèles dans le script SQL de post-déploiement également, comme le montre l’exemple de contenu de script suivant : GRANT reference_usage on database provider_data to share in entity <% fn.str_to_id(ctx.entities.myapp_pkg.identifier) %> Copy
meta.use_mixins optional, sequence	Noms des mixins à appliquer à cette entité. Pour plus d’informations, voir Mixins de projets

Propriétés de l’entité du paquet d’application¶

Le tableau suivant décrit les propriétés communes disponibles pour les entités de paquet d’application pour les Native Apps. Voir Spécifier des entités pour plus d’informations sur les entités de définition de projet.

Propriétés pour les entités de `paquet d'application`¶
Propriété	Définition
type required, string	Doit être `application package`.
manifest required, string	L’emplacement du fichier Snowflake Native App `manifest.yml` dans votre projet.
deploy_root optional, string	Sous-dossier à la racine de votre projet dans lequel l’étape de construction copie les artefacts. Une fois copiés à cet endroit, vous pouvez les déployer dans une zone de préparation Snowflake. Par défaut : `output/deploy`
generated_root optional, string	Sous-répertoire de la racine de déploiement où Snowflake CLI écrit les fichiers générés. Par défaut : `__generated`
stage optional, string	Identificateur de la zone de préparation qui stocke les artefacts de l’application. La valeur utilise le formulaire `<schema_name>.<stage_name>`. La zone de préparation se trouve à l’intérieur de l’objet « Paquet d’application ». Vous pouvez changer le nom pour éviter les collisions de noms. Par défaut : `app_src.stage`
artifacts required, sequence	Liste des paires de fichiers source et destination à ajouter à la racine du déploiement, ainsi que le processeur d’annotation Snowpark optionnel. Vous pouvez utiliser les propriétés d’artéfacts suivantes : `src` : chemin vers le ou les fichiers sources du code `dest` : chemin vers le répertoire dans lequel déployer les artefacts. Les chemins de destination qui font référence à des répertoires doivent se terminer par un `/`. La destination d’un modèle de glob qui ne se termine pas par `/` entraîne une erreur. S’il est omis, `dest` prend par défaut la même chaîne que `src`. Vous pouvez également transmettre une chaîne pour chaque élément au lieu d’un `dict`, auquel cas la valeur est traitée à la fois comme `src` et `dest`. `processors` : nom du processeur à utiliser pour traiter les fichiers de code `src`. Voir Plus d’informations sur les processeurs d’artefacts pour plus de détails. Si `src` fait référence à un seul fichier (pas un glob), `dest` peut faire référence à un `<chemin>` ou `<chemin/nom>` cible. Vous pouvez également transmettre une chaîne pour chaque élément au lieu d’un `dict`, auquel cas la valeur est traitée à la fois comme `src` et `dest`. Exemple sans processeur : pkg: artifacts: - src: app/* dest: ./ - src: streamlit/* dest: streamlit/ - src: src/resources/images/snowflake.png dest: streamlit/ Copy Exemple avec un processeur : pkg: artifacts: - src: qpp/* dest: ./ processors: - name: snowpark properties: env: type: conda name: <conda_name> Copy
distribution optional, string	Distribution du paquet d’application créé par Snowflake CLI. Lors de l’exécution des commandes `snow app`, Snowflake CLI vous avertit si le paquet d’application avec lequel vous travaillez a une valeur de distribution différente de celle définie dans la définition de votre projet résolu. Par défaut : `Internal`
scratch_stage optional, string	Identificateur de la zone de préparation qui stocke les données temporaires utilisées par Snowflake CLI. La valeur prend la forme suivante : `<schema_name>.<stage_name>`. La zone de préparation se trouve à l’intérieur de l’objet « Paquet d’application ». Vous pouvez changer le nom pour éviter les collisions de noms. Par défaut : `app_src.stage_snowflake_cli_scratch`

Propriétés de l’entité d’application¶

Le tableau suivant décrit les propriétés communes disponibles pour les entités d’application pour les Native Apps. Voir Spécifier des entités pour plus d’informations sur les entités de définition de projet.

Propriétés pour les entités `application`¶
Propriété	Définition
type required, string	Doit être `application`.
from.target required, string	Paquet d’application à partir duquel créer cette entité d’application. Dans l’exemple suivant, `target` définit le nom d’une entité dans le fichier `snowflake.yml`. from: target: my_pkg Copy
debug optionnel, booléen	Permet d’activer ou non le mode débogage lors de l’utilisation d’une zone de préparation nommée pour créer une application. Par défaut : `True`

Plus d’informations sur les processeurs d’artefacts¶

Si vous incluez le champ artifacts.processors dans le fichier de définition du projet, la commande snow app bundle appelle un traitement personnalisé pour les fichiers de code Python dans le répertoire ou le fichier src.

Cette section couvre une liste des processeurs pris en charge.

Processeur Snowpark¶

L’un des processeurs pris en charge par Snowflake CLI est snowpark, qui applique le traitement des annotations Snowpark aux fichiers Python. Ce qui suit montre la structure et la syntaxe de base pour différents environnements de traitement :

Pour exécuter du code dans un environnement conda, utilisez ce qui suit :

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

Copy

où <conda_name> est le nom de l’environnement conda contenant l’interpréteur Python et la bibliothèque Snowpark que vous souhaitez utiliser pour le traitement des annotations Snowpark.

Pour exécuter du code dans un environnement virtuel Python, utilisez ce qui suit :
```
pkg:
  artifacts:
    - src: <some_src>
      dest: <some_dest>
      processors:
          - name: snowpark
            properties:
              env:
                type: venv
                path: <venv_path>
```
Copy
où <venv_path> est le chemin de l’environnement virtuel Python contenant l’interpréteur Python et la bibliothèque Snowpark que vous souhaitez utiliser pour le traitement des annotations Snowpark. Le chemin peut être absolu ou relatif au répertoire du projet.

Pour exécuter du code dans l’environnement actuellement actif, utilisez l’une des définitions équivalentes suivantes :

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

Copy

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

Copy

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

Copy

Pour plus d’informations sur le traitement personnalisé, voir les commandes Génération automatique de code SQL et snow app bundle.

Processeur de modèles¶

Les projets Snowflake Native App prennent en charge les modèles dans des fichiers arbitraires, ce qui vous permet d’étendre les modèles dans tous les fichiers d’un répertoire src d’artefact. Vous pouvez activer cette fonctionnalité en incluant un processeur templates dans la définition artifacts désirée, comme le montre l’exemple suivant :

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

Copy

Quand Snowflake CLI télécharge les fichiers vers une zone de préparation, il développe automatiquement les modèles avant de les télécharger. Par exemple, supposons que votre application contenue dans un fichier app/README.md avec le contenu suivant qui inclut le modèle <% ctx.entities.pkg.identifier %> :

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

Copy

Le modèle est ensuite étendu comme suit avant de télécharger le fichier vers une zone de préparation :

This is a README file for application package myapp_pkg.

Copy

Remplacements de la définition du projet¶

Bien que votre répertoire de projet doive contenir un fichier snowflake.yml, vous pouvez choisir de personnaliser le comportement de Snowflake CLI en fournissant des modifications locales dans snowflake.yml, telles qu’un nouveau rôle pour tester votre propre paquet d’application. Ces remplacements doivent être placés dans le fichier snowflake.local.yml qui se trouve à côté de la définition du projet de base. Snowflake vous suggère de l’ajouter à votre fichier .gitignore afin qu’il ne soit pas contrôlé par git. Tous les modèles fournis par Snowflake l’incluent déjà dans le fichier .gitignore.

Ce fichier de remplacements doit se trouver au même endroit que votre fichier snowflake.yml.

Le fichier snowflake.local.yml reprend exactement le même schéma que le fichier snowflake.yml, à ceci près que toutes les valeurs qui étaient obligatoires sont désormais facultatives, en plus des valeurs déjà facultatives. Vous trouverez ci-dessous un exemple de fichier snowflake.local.yml :

entities:
  pkg:
    meta:
      role: <your_app_pkg_owner_role>
      name: <name_of_app_pkg>
      warehouse: <your_app_pkg_warehouse>
  app:
    debug: <true|false>
    meta:
      role: <your_app_owner_role>
      name: <name_of_app>
      warehouse: <your_app_warehouse>

Copy

Chaque commande snow app donne la priorité aux paramètres de ce fichier sur ceux définis dans le fichier de configuration de base snowflake.yml. Des valeurs par défaut raisonnables permettent déjà d’isoler les développeurs qui utilisent le même compte Snowflake pour développer le même projet d’application. Si vous débutez, nous vous suggérons de ne pas inclure de fichier de remplacements.

Le schéma de définition final obtenu après avoir remplacé snowflake.yml par snowflake.local.yml est appelé définition de projet résolue.

Limitations¶

Actuellement, Snowflake CLI ne prend pas en charge

les fichiers de remplacements multiples.
Un fichier de remplacement vierge. Ne créez ce fichier que si vous souhaitez remplacer une valeur de snowflake.yml.