GitHub user dfbustosus added a comment to the discussion: Superset 6.1: is flask-caching still structurally required when runtime uses NullCache and SupersetMetastoreCache?
Assuming "6.17" means Superset `6.1.0`: yes, `flask-caching` remains structurally required even when no external cache service is configured. It is an unconditional runtime dependency in [`pyproject.toml`](https://github.com/apache/superset/blob/c83fb2bb1dcfac41ac51bcebd82471f4a7180d18/pyproject.toml#L39-L56), and the generated 6.1.0 requirements pin [`flask-caching==2.3.1`](https://github.com/apache/superset/blob/c83fb2bb1dcfac41ac51bcebd82471f4a7180d18/requirements/base.txt#L120-L132). It is also required by the implementation: - [`SupersetCache` subclasses `flask_caching.Cache`](https://github.com/apache/superset/blob/c83fb2bb1dcfac41ac51bcebd82471f4a7180d18/superset/utils/cache_manager.py#L20-L26). - [`CacheManager` constructs and initializes those cache objects](https://github.com/apache/superset/blob/c83fb2bb1dcfac41ac51bcebd82471f4a7180d18/superset/utils/cache_manager.py#L186-L237). - [`SupersetMetastoreCache` subclasses `flask_caching.BaseCache`](https://github.com/apache/superset/blob/c83fb2bb1dcfac41ac51bcebd82471f4a7180d18/superset/extensions/metastore_cache.py#L20-L42). Therefore, `NullCache` means "use a no-op runtime backend"; it does not bypass the Flask-Caching extension. `SupersetMetastoreCache` is likewise a custom Flask-Caching backend, not a replacement for that package. There is no supported configuration-only way to remove the dependency while staying on 6.1.0. Installing with `--no-deps` or deleting it leaves imports unresolved during startup. The supported options are to have the quarantined `2.3.1` release reviewed and allowed through your mirror, use another approved mirror, or maintain a downstream fork replacing Superset's caching integration. Redis or Memcached is not required for the runtime configuration shown. For a future multi-instance deployment, Redis is the documented general choice: use a private endpoint, authentication supplied through a secret manager, TLS where supported, distinct key prefixes/logical databases, and appropriate HA. Keep Flask-Caching backends, Celery broker/results, and distributed coordination as separately configured concerns. Memcached can support general Flask-Caching use, but cannot replace Redis-specific coordination. Current cache configuration and recommendations are documented [here](https://github.com/apache/superset/blob/c83fb2bb1dcfac41ac51bcebd82471f4a7180d18/docs/versioned_docs/version-6.0.0/configuration/cache.mdx#L8-L52). GitHub link: https://github.com/apache/superset/discussions/44823#discussioncomment-18687296 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
