Caching

[jwokaty]

@RonaldRonnie said

I’m running BioAnalyzer using docker compose with bind mounts like:
 ./app:/app/app and ./results:/app/results.
When I update code (e.g. Streamlit curator table / backend python files), sometimes the container doesn’t reflect changes unless I rebuild.
What’s the recommended approach here to ensure Docker always picks up local changes without rebuilding?

Should I rely entirely on bind mounts + container restart?
Or should I run in a “dev mode” image with reload enabled?
Any best practice for Streamlit inside the container?
I appreciate any guidance given.

Regarding updated code for Streamlit in curator_table and the backend python files, if they are not bind mounted, you have to rebuild because the container is just using what was copied at docker compose up.

For changes that happen while the application is running, you need to make Streamlit watch and uvicorn to reload. You have an option to make uvicorn reload. Maybe verify it is working correctly and that you are setting it to True:

bioanalyzer-backend/main.py

Lines 27 to 32 in a8573c9

	def _should_reload(args: argparse.Namespace) -> bool:
	"""Determine if auto-reload should be enabled."""
	if args.reload:
	return True
	reload_env = os.getenv("UVICORN_RELOAD", "false").lower()
	return reload_env in ("true", "1", "yes")

For Streamlit changes to happen, "watch"-related settings should be set. By default it watches the current working directory (I'm not sure where it thinks that is, but you can specify paths explicitly if needed). You probably at least should make server.runOnSave true as it is false by default: https://docs.streamlit.io/develop/api-reference/configuration/config.toml#server.

You could have a compose file for dev or document how to set configurations for a dev environment. I think the depends on the complexity of configuration.

Although I had one experience running Streamlit in a container and on bare metal, I am not so familiar with it. Right now it is contained within curator_table within the repository. My first thought is could it be a separate service and repository? It might reduce the complexity but it might take a lot of work to separate it. I wouldn't change it for the moment; let me think about this a little more.

I haven't tried running your code, only reading it and some documentation. I'll try on Friday.