Dependencies: packages, wheels, and requirements.txt

The three ways an app gets its Python dependencies — the packages key, wheel files in modules/, and requirements.txt — and which one applies to your app.

There are three mechanisms for giving your app's Python models their dependencies, and which ones apply depends on how the app runs (SBT Beta vs SBT 1.0). "Which of these do I use?" is one of the most common points of confusion, so here is the whole picture.

Quick decision table

You need

Beta app (--beta, stored procedures)

1.0 app (containers)

A common public package (numpy, scikit-learn...)

packages: key on the model config

requirements.txt

Seek's internal libraries (e.g. seek_cpg) or any private code

A wheel file in modules/ + py_modules: key

requirements.txt (or a wheel referenced there)

snowflake-snowpark-python

Provided; list it in packages: by convention

requirements.txt

Mechanism 1: the packages: key (Beta)

A list on the model config of packages to make available inside the Snowflake stored procedure. These must be Anaconda-channel package names (Snowflake's built-in package repository) — arbitrary PyPI packages will not work here.

models:
  - name: my_model
    config:
      language: python
      packages:
        - "snowflake-snowpark-python"
        - "numpy"

Mechanism 2: wheel files — the modules/ folder + py_modules: (Beta)

A wheel file (.whl) is a zipped, pre-built Python library. This is how beta apps use code that isn't on the Anaconda channel — most commonly Seek's internal analytics libraries (for example seek_cpg, the built version of the seek-modeling repo).

How it works:

  1. Put the wheel file in your project's modules/ folder (or the folder named by py_modules_path in your app config).

  2. List its filename in the model's py_modules: key:

models:
  - name: my_model
    config:
      language: python
      packages:
        - "snowflake-snowpark-python"
      py_modules:
        - seek_cpg-15.0.2-py3-none-any.whl

  1. At build time, sbt uploads the wheel; at deploy time it is attached to the model's stored procedure and unpacked at runtime, so import seek_cpg works inside your model function.

Note the import placement rule for beta models: import wheel-provided packages INSIDE def model(session, seek):, never at the top of the file (see Models > How models execute).

Different apps can pin different wheel versions — each model's py_modules lists the exact filename it needs, and multiple wheel versions can coexist in modules/.

Mechanism 3: requirements.txt (1.0)

On the 1.0 path, apps run in containers, and requirements.txt is the source of truth: it is uploaded at build time and pip-installed when the app's image is built. Standard pip syntax, including version pins and wheel references.

The packages: and py_modules: keys are the beta-era mechanisms; on the 1.0 path requirements.txt replaces them. (Per-model or multiple named requirements files are under discussion for apps that need different dependency sets — check with the Creator team for current status.)

Which world is my app in?

All current production apps are beta (published with --beta): use packages: and py_modules:. When your app migrates to 1.0, dependencies move to requirements.txt — see the SBT 1.0 App Migration Guide.

Related articles

⏭️ Next: RLS Parameters (Row-Level Security)