Configuring Streamlit dependencies with requirements.txt #3137

Hi! I think this is a valid distinction to raise.

As far as I can tell, snow streamlit deploy does not currently provide the same dependency-resolution and packaging workflow as snow snowpark build. For a warehouse-runtime Streamlit app, dependencies are declared in environment.yml and must be available from the Snowflake Anaconda Channel. snow streamlit deploy uploads the application artifacts, but it does not appear to traverse requirements.txt and automatically build a ZIP containing the missing PyPI dependencies.

The snow snowpark package create and snow snowpark package upload commands can build and upload packages that are unavailable from the Snowflake Anaconda Channel, including their non-Anaconda Python dependencies. However, the documented workflow is specifically intended for imports used by Snowpark procedures and functions. Therefore, I would treat the proposed dependencies.zip approach for a warehouse-runtime Streamlit app as an experiment rather than as a documented or guaranteed deployment workflow.

The situation is different for the newer Container Runtime. A container-runtime Streamlit app can declare PyPI dependencies directly through requirements.txt or pyproject.toml, and the runtime resolves the transitive dependency tree. For example:

my_app/
|________streamlit_app.py
|________ requirements.txt
|_______ snowflake.yml

# requirements.txt
some-package==1.2.3
another-package>=4.0,<5.0

The application must be configured with an external access integration that allows access to the selected package index. Without that integration, the container runtime can only use its preinstalled packages or wheel files included in the application source. So I would summarize the current options as follows:

• Warehouse Runtime: use environment.yml; packages are limited to the Snowflake Anaconda Channel.
• Container Runtime: use requirements.txt or pyproject.toml; PyPI and other compatible package indexes are supported through an external access integration.
• Manually packaged ZIP: potentially worth testing for a warehouse-runtime app, but the existing snow snowpark package documentation targets Snowpark functions and procedures rather than Streamlit deployment.

Therefore, I agree that a Streamlit-specific build command analogous to snow snowpark build could still be useful for users who must remain on the warehouse runtime. Container Runtime addresses the dependency problem for new applications, but it does so by providing a different runtime and package-management model rather than by adding automatic dependency packaging to snow streamlit deploy.

[1] https://docs.snowflake.com/en/developer-guide/streamlit/app-development/runtime-environments
[2] https://docs.snowflake.com/en/developer-guide/streamlit/app-development/dependency-management
[3] https://docs.snowflake.com/en/developer-guide/streamlit/migrations-and-upgrades/runtime-migration
[4] https://docs.snowflake.com/en/developer-guide/snowflake-cli/snowpark/upload