Question
PyScript and Pyodide: Managing Stale Cache in <py-script> src Files
Nia Byte
0 reputation · 05 Aug 2021, 09:11 UTC
128.2K views1
Loading…
0 reputation · 05 Aug 2021, 09:11 UTC
The goal is to guarantee that a Python script referenced via a <py-script src="..."> tag runs the most recent version after the source file changes on the server. PyScript caches fetched scripts in Pyodide’s virtual filesystem and reuses them across reloads unless the URL or cache validator indicates a newer version. This depends on HTTP headers such as ETag or Last‑Modified and on the <py-config cache> attribute, which defaults to true.
Documentation does not clearly state whether PyScript automatically invalidates cached <py-script> src files when the server updates the file with a new ETag or Last‑Modified header, or whether developers must use manual cache busting, such as appending a query‑parameter version, to force a fresh fetch.
Given these constraints, what is the recommended strategy for ensuring fresh execution of an updated <py-script> src file on each page load? 1) Does PyScript honor ETag/Last‑Modified headers to invalidate its cache automatically? 2) Is setting <py-config cache="false"> or adding a URL query parameter the best approach, or is there a different method? 3) How does the <py-config cache> setting interact with HTTP caching across PyScript releases?
34775 reputation · 05 Aug 2021, 11:49 UTC
To guarantee that a Python script referenced via <py-script src="..."> runs the most recent version after a server-side update, the most reliable strategy is cache busting by appending a version or content-hash query parameter to the source URL (e.g., src="main.py?v=1.0.2").
It is important to distinguish between the Pyodide virtual filesystem and the browser's HTTP cache. Pyodide's in-memory filesystem is volatile and does not persist across full page reloads. Therefore, if a <py-script> tag loads a stale file, the issue resides in the browser's HTTP cache, not Pyodide's internal storage.
Because PyScript fetches external source files using the browser's fetch API, it inherently honors standard HTTP caching rules. If your server provides valid ETag or Last-Modified headers, the browser will perform a conditional request. If the file has changed, the server returns a 200 OK with the new content; if not, it returns a 304 Not Modified.
| Method | Mechanism | Reliability | Trade-off |
|---|---|---|---|
| Query Parameters | src="file.py?v=123" |
Highest | Requires build-step automation |
| Cache-Control | no-cache header |
High | Extra network round-trip per load |
| HTTP Validators | ETag / Last-Modified |
Medium | Dependent on server configuration |
If you cannot automate version strings in your URLs, configure your server to send Cache-Control: no-cache for .py files. This forces the browser to revalidate the file with the server before using a cached copy.
pyscript.py file.200 (from disk cache): The browser is bypassing the server entirely (stale).304 Not Modified: The browser checked the server and the file is current.200 OK: A fresh copy was downloaded.The <py-config> attributes have evolved significantly across PyScript releases. Because the underlying fetch mechanism relies on the browser's network stack, relying on a specific cache="false" attribute is less predictable than managing the HTTP headers or the URL itself.
Diagnostic Detail Needed: To provide a more specific configuration, please specify the PyScript version currently in use (e.g., 2023.x or the newer PyScript Next), as the configuration schema varies between releases.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.