feat(streamlit): resolve STREAMLIT grants at plan time (fetch_streamlit)

[usbrandon]

What

snowcap plan errors whenever a grant references a Streamlit app:

module 'snowcap.data_provider' has no attribute 'fetch_streamlit'

StreamlitPriv, SchemaPriv.CREATE_STREAMLIT, and the Streamlit resource class already exist, so grant SQL renders — but because Streamlit has a concrete resource class, resolving on: streamlit <db>.<schema>.<app> drives fetch_resource → fetch_streamlit, which is missing.

Change

• snowcap/data_provider.py: add fetch_streamlit() — SHOW STREAMLITS + DESC STREAMLIT, mapping root_location → from_, plus main_file/title/query_warehouse/comment/owner (mirrors fetch_notebook).
• tests/test_grant.py: test_grant_on_streamlit.
• tests/test_privs.py: TestStreamlitPriv.
• docs/resources/streamlit.md: "Granting access" section; docs/resources/grant.md: streamlit example.

Validation

Verified end-to-end against a live account: GRANT USAGE ON STREAMLIT now plans and applies (the previously-fatal fetch error is gone; the grant shows as a normal create). Full unit suite green.

🤖 Generated with Claude Code

[noel]

Thanks for this, @usbrandon — clean, well-scoped fix and the live validation is appreciated. Modeling it on fetch_notebook is the right call. A few specific changes I'd like before merge:

Requested changes

1. Resolve the from_ / root_location drift. DESC STREAMLIT returns root_location as a fully-qualified, uppercased stage path (e.g. @DB.SCHEMA.MY_STAGE/app), while users declare from_="@my_stage". As written, stage-based apps will likely show perpetual drift. Please either drop from_ from the returned dict (as fetch_notebook does) or normalize root_location back to the declared form. If you can, add a plan run against an app whose config omits/short-forms from_ to confirm it reports no change.

2. Handle the main_file default. fetch_notebook maps its default (notebook_app.ipynb) to None so an omitted field doesn't drift. Please apply the same treatment for Streamlit's default main_file (e.g. streamlit_app.py) → None.

3. version hardcoded to None. Fine for stage apps, but a repo-based app (from_=https://…, version="main") would drift on version. Either populate it from the DESC/SHOW output or add a short code comment noting the known limitation.

Nits

• Add trailing newlines to docs/resources/streamlit.md and docs/resources/grant.md.

Looks good

• Return dict matches the _Streamlit spec field-for-field.
• Using .get() / or None is more defensive than fetch_notebook — nice.
• The owner's-rights explanation in the docs is correct and genuinely helpful.

No concern about the lack of a direct fetch_streamlit unit test — that's consistent with the rest of the fetch functions. Thanks again!

[usbrandon]

All requested changes are in, plus live validation against a real account.

Requested changes

1. from_ drift: dropped from_ from the fetch_streamlit dict and marked it fetchable: False on _Streamlit, mirroring _Notebook. YAML is now authoritative for from_.
2. main_file default: streamlit_app.py now maps to None, same treatment as notebook_app.ipynb.
3. version: kept as None with a code comment noting the limitation for repo-based apps — DESC STREAMLIT doesn't return a comparable value.

Live validation (short-form from_, main_file omitted, exactly the scenario you asked for):

• Created a stage + app with CREATE STREAMLIT ... FROM '@APP_STAGE', then planned against a config declaring from_: "@app_stage" and no main_file.
• Result: Plan: 0 to create, 0 to update — no drift. (The single transfer line is ownership only, expected since the test config omitted owner.)
• Control on the pre-fix commit: old fetch returned from_: None vs the declared @app_stage — drift confirmed. Worth noting: on this account DESC STREAMLIT has no root_location column at all (newer versioning model), so the old code drifted on every stage app.

Also fixed a pre-existing blocker: Streamlit defined init instead of __init__, so declaring a streamlit in YAML failed with Invalid key "from_" — this is broken on main too. Renamed to __init__ (matching every other resource) and defaulted from_ to None on the spec/init since it's now non-fetchable. Unit suite: 1537 passed.

Nits: added the trailing newline to docs/resources/streamlit.md; docs/resources/grant.md already ends with one on this branch.

[usbrandon]

Pushed two fixes for the failing checks. Neither failure originated in this PR — details below in case they're useful beyond this branch.

1. build (3.12) — pre-existing flake in tests/test_data_provider.py (479b027)

TestFetchGrantsFromAccountUsage::test_returns_none_on_access_control_error failed with:

assert [{'created_on': ..., 'privilege': 'SELECT', 'name': 'MY_DB.MY_SCHEMA.MY_TABLE', ...}] is None

The four ACCOUNT_USAGE caches in data_provider.py are keyed by id(session), but the six test classes covering them cleared only _ACCOUNT_USAGE_ACCESS_CACHE and _ACCOUNT_USAGE_FALLBACK_CACHE in setup_method — _ACCOUNT_USAGE_GRANTS_CACHE and _ACCOUNT_USAGE_USER_GRANTS_CACHE survived between tests.

CPython reuses the address of a freed object, so a fresh MagicMock() session frequently lands on the previous test's address (measured: 169 id() collisions per 200 sequential MagicMock()s, 31 unique addresses). When that happens, the error test hits the grant list cached by test_returns_normalized_grants at the cache check in _fetch_grants_from_account_usage and returns early, never reaching the except branch.

Fix: one autouse fixture in the root conftest.py calling the existing reset_account_usage_caches() helper, replacing the six partial setup_method clears. Root conftest rather than module-local because pytest runs --dist loadfile, so a worker can host several test files.

Worth noting this isn't 3.12-specific — with the collision forced it reproduces on 3.10 and 3.11 as well; those jobs were just lucky with allocation ordering.

2. All three jobs — ruff 0.16 (d68b5fd)

The next run failed earlier, at ruff check snowcap/, on 3.10/3.11/3.12 alike — before mypy or pytest ran. The dev extra declared a bare "ruff", and 0.16.0 expanded the default rule set (I001, RUF100, UP0xx, SIM1xx, TRY0xx, …).

This is repo-wide rather than branch-specific. Against a pristine origin/main tree:

tree	ruff 0.15.22	ruff 0.16.0
origin/main	All checks passed	723 errors
this branch	All checks passed	725 errors

main looks green only because its last Run Tests predates the 0.16 release. Any PR opened today hits this.

Fix: pin ruff<0.16 in the dev extra, restoring the linter CI was passing with. The durable alternative is declaring the rule selection explicitly under [tool.ruff.lint] in pyproject.toml so future ruff releases can't change what's enforced — happy to do that instead if you'd prefer; it's your lint policy, so I left it alone.

Verification

Real venvs per interpreter, running CI's exact commands:

	ruff	mypy	pytest	forced id() collision (before → after)
3.10.18	pass	34 files clean	1537 passed	fails → passes
3.11.13	pass	34 files clean	1537 passed	fails → passes
3.12.12	pass	34 files clean	1537 passed	fails → passes
3.13.9	pass	34 files clean	1537 passed	fails → passes

3.13 included since python_requires=">=3.10" has no upper bound — you may want "3.13" in the run-tests.yml matrix, but I didn't change the workflow here.

One thing I did not fix

Keying those caches by id(session) is also a production hazard, not just a test artifact: nothing holds a reference to the session, so a garbage-collected connection leaves its grant list behind, and a new connection allocated at the same address inherits it — stale grants at plan time. Out of scope here; happy to open a separate PR (weakref-keyed caches across the 8 session_id = id(session) sites) if you want it.

[noel]

Thanks @usbrandon — reviewed and this looks solid. Confirmed the key pieces: the init → __init__ rename is a genuine fix (on main, Streamlit defined def init, which is never called during construction, so the class was effectively unconstructible), fetch_streamlit is correctly wired via the fetch_{resource_label} naming convention, and the DESC STREAMLIT access mirrors fetch_notebook.

One small note before merge: making from_ optional (field(default=None)) removes a construction-time guardrail. It's correct for the fetch path (from_ is fetchable=False, so drift is ignored), but a create spec authored in YAML without from_ will now construct fine and only fail later at apply time with a malformed CREATE STREAMLIT (no ROOT_LOCATION). Worth a create-time check that from_ is present when the spec is being created rather than fetched. Not a blocker — happy to merge with or without it.