[ENH] Refactor progress bar backend to allow user choice#638
Conversation
…rich - Create progress utility module with configurable backends (rich, tqdm, none) - Update config default to 'simple' and fix metadata - Make rich an optional dependency - Update all hard-coded rich imports to use the utility - Handle progress bar selection in tabular_model callbacks
fkiraly
left a comment
fkiraly
left a comment
There was a problem hiding this comment.
Thanks! Though, are you sure this makes rich optional? It is still being used as hard-coded option without an alternative in some places (see above)
- Change internal utilities to use 'none' backend to avoid rich dependency - Update sweep and tuner to use 'simple' instead of 'rich' when progress enabled - Refactor predict method to use progress utility instead of manual backend checks - Ensure all progress usage is configurable and doesn't force rich dependency
- Update get_progress_tracker and get_progress_context defaults from 'rich' to 'none' - Ensures no hard-coded rich usage in utility functions - Rich is now truly optional with graceful fallback
- Update fallback lambda functions to accept **kwargs to handle description and other parameters - Prevents TypeError when progress tracker is called with keyword arguments
…allback selection - Create get_progress_bar_callback() function for choosing progress bar callbacks - Refactor _prepare_callbacks to use the utility instead of manual if/elif logic - Further decouples progress bar handling from direct Lightning imports
|
It would be appreciated if you would comment on my question. |
Rich is now truly optional. The refactoring completely decouples rich from core functionality by moving it to extra dependencies, implementing safe "none" defaults across all progress utilities, wrapping every rich import in try/except blocks with graceful no-op fallbacks, and abstracting all progress usage through configurable utilities that handle missing dependencies elegantly. The library imports and runs fully without rich installed, with all progress functionality degrading to no-ops while preserving user choice to opt into rich via configuration. |
|
great - let´s see what happens in the tests |
fkiraly
added
enhancement
|
@fkiraly The issue was that I removed the |
|
@fkiraly Could you run workflows on this again as I fixed the issue that was arising before. |
2 participants
rich, investigaterichproblems #605