fastprogress 1.1.0 switched from raw HTML strings to fasthtml FT components for Jupyter rendering. The problem is the transitive dep chain this introduces:
fastprogress -> python-fasthtml -> fastlite -> apswutils -> apsw
apsw is a SQLite C extension that needs pre-built wheels or a compiler. Poetry can't find wheels for some platforms, so poetry install just fails -- which blocks anything that depends on fastprogress (in my case, blackjax -- It seems the blackjax team is also tracking this on their end: blackjax-devs/blackjax#812).
fastprogress only uses 9 tag constructors (Div, Progress, Table, Tr, Td, Th, Thead, Tbody, P) but python-fasthtml also drags in starlette, uvicorn, httpx, oauthlib, beautifulsoup4, etc. That's a lot of weight for a progress bar.
The old f-string approach in core.py still exists and worked fine. Could the fasthtml dep be made optional with a fallback to the f-string versions? Or even just vendor the few FT helpers that are actually needed?
My workaround for this is to pin fastprogress<1.1 in my project.
fastprogress 1.1.0 switched from raw HTML strings to fasthtml FT components for Jupyter rendering. The problem is the transitive dep chain this introduces:
apsw is a SQLite C extension that needs pre-built wheels or a compiler. Poetry can't find wheels for some platforms, so
poetry installjust fails -- which blocks anything that depends on fastprogress (in my case, blackjax -- It seems the blackjax team is also tracking this on their end: blackjax-devs/blackjax#812).fastprogress only uses 9 tag constructors (Div, Progress, Table, Tr, Td, Th, Thead, Tbody, P) but python-fasthtml also drags in starlette, uvicorn, httpx, oauthlib, beautifulsoup4, etc. That's a lot of weight for a progress bar.
The old f-string approach in core.py still exists and worked fine. Could the fasthtml dep be made optional with a fallback to the f-string versions? Or even just vendor the few FT helpers that are actually needed?
My workaround for this is to pin
fastprogress<1.1in my project.