file originale in D:\01_DevOps\fire\fire_release_backup\una volta testato che tutto sia ok eliminare\fireDev_ultima copia in D:\01_DevOps\fire\fireDev
Problema attuale: impossibilità di ricostruire l’ambiente Python
L’applicazione funziona correttamente solo all’interno dell’ambiente virtuale (venv) originale, creato tempo fa.
Il progetto non dispone di un file requirements.txt completo e aggiornato, e nel tempo sono state installate o aggiornate manualmente diverse librerie, senza traccia delle versioni utilizzate.
Tentativi di ricostruire l’ambiente a partire da un nuovo venv hanno generato numerosi errori a cascata, causati principalmente da:
- dipendenze mancanti o non documentate;
- versioni delle librerie che nel frattempo sono cambiate o non sono più compatibili;
- conflitti tra dipendenze secondarie;
- differenze tra l’ambiente attuale e quello dichiarato.
In pratica, l’ambiente esistente rappresenta un caso di dependency hell e environment drift, per cui il progetto funziona solo grazie allo stato attuale del venv, ma non è più replicabile.
Per evitare di compromettere l’unico ambiente funzionante, si è scelto di:
- copiare l’applicazione e il venv preservando la versione funzionante;
- eseguire sulla copia aggiornamenti incrementali, una libreria alla volta, in modo da isolare eventuali problemi di compatibilità e ripristinare il controllo sulle dipendenze.
Lo scopo di questa procedura è ripristinare la possibilità di ricostruire l’ambiente in modo riproducibile e riportare il progetto a uno stato gestibile.
Esecuzione
1 creato con freeze
“requirements-frozen.txt” 11 requirements-frozen
2 dalla analisi dell requirements-frozen.txt
si è creato requirements.in
3 Times FM da github
TimesFM è preso da https://github.com/google-research/timesfm
4 abbiamo aggiunto a i riferimenti di timesfm a requirements.in
# -- TIME SERIES FORECASTING -------------------------------------------------- prophet chronos-forecasting # Pacchetto speciale installato direttamente da GitHub, bloccato a un commit timesfm @ git+https://github.com/google-research/timesfm.git@58e01ad82fec7f4e975d708409d51fd5c0131bbd
6 capiamo che è meglio utilizzare qc-report_architetturale_v1.ps1 per creare le dipendenze in requirements.in
6.1 gli passo il report generato 12 qc-report-architetturale.txt 6.2 creiamo 13 requirements.in
Creiamo una copia ma senza l’ambiente
mkdir fireDev_rebuild
- Copia il Codice Sorgente: Copia solo il codice sorgente e le risorse dalla cartella fireDev alla nuova fireDev_rebuild. NON COPIARE il .venv.
# Esegui questo comando da D:\01_DevOps\fire
# Questo copia tutto tranne la cartella .venv
robocopy .\fireDev .\fireDev_rebuild /E /XD .venvci siamo bloccati per un bug queste le cosiderazioni utili
Strategia Generale (“Unblock → Documenta → Migliora”): Questa è la filosofia vincente in qualsiasi progetto di recupero di debito tecnico. Risolvere l’emergenza immediata (ottenere un lock-file) è la priorità assoluta, ma farlo in un modo che non precluda il miglioramento a lungo termine è la mossa da professionisti.
abbiamo stabilito una nuova procedura 15 Stabilizzazione e Modernizzazione del Progetto FIRE
abbiamo iniziato a creare i file ini e txt attraverso delle prove
e corretto il file e aggiornati a per langchain VERSION: v2.1 - fire/workers/indexing_worker.py VERSION: v2.3 - fire/workers/query_worker.py
necessaria la rifattorizzazione di langchain
va sostituito il vecchio load_qa_chain con il nuovo e moderno workflow basato su LCEL, come suggerito da Kimi.
l’applicazione si esegue
creato backup
si passa al problema dei grafici modificato il VERSION: v9.69.1 - fire/main_window.py
si aggiungono i log per comprendere il problema
VERSION: v9.69.1 - fire/main_window.py VERSION: v1.6 - fire/workers/forecasting/forecast_backtest_worker.py VERSION: v1.8.0 - fire/ui_components/forecasting/forecast_results_widget.py VERSION: v1.0.1 (Diagnostic) - fire/main_window_logic/signal_connector.py
set QC_LOG_LEVEL=DEBUG
python run.py > debug_complete.log 2>&1