virtualdj
Refactor to Interfaces and Enums
Reasoning:
Vista la discussione riguardante il calcolo del prezzo totale della bolletta, i possibili cambi riguardo i prezzi e l'attuale mancanza di un metodo per impostare un tipo di contratto (il prezzo della fascia corrente e' sempre basato sul multifascia, mentre dovrebbe essere basato sul tipo di contratto (mono/bi/multi) Ho quindi migrato parte del programma a una struttura OOP implementando Interfacce per poter definire le strutture di dati e rendere il check e la modifica delle stesse piu' semplice e intuitivo. questo aiuta anche nell'auto-complete in IDE e aggiunge un livello di typesafety per le funzioni da chiamare.
Una lista dei cambiamenti piu' rilevanti:
- il Coordinator ora e' un modulo a parte (coordinator.py) come suggerito nelle docs di HA.
- le funzioni helper sono state spostate in utils.py
- Created Interface per PunData e PunValues e Fasce
- Creati Enum per fasce
- Semplificato Retry timer in caso di errore di connessione
- aggiunto caso in cui lo ZIP non e' valido ma la connessione e' avvenuta con successo ( da gestire come si vuole, per ora rimanda a domani)
- aggiunti 'type: ignore' per i falsi positivi, La codebase ora non dovrebbe dare errori o warning nell'IDE
RELEASE:
Ho aggiunto una Github Action che Bumpa e crea una versione nelle release per ogni push/PR sul master, purtroppo per ora non sono riuscito a trovare un modo per fargli bumpare anche la versione in manifest.json, quindi abbiamo un mismatch tra le due, ma non comporta reali problemi in quanto HACS prende il numero nelle release di github. Inoltre cosi' facendo e' possibile distribuire versioni beta in pre-release.
E' consigliato utilizzare un branch e fare un PR invece che pushare sul main direttamente, in questo modo e' possibile modificare il tipo di release (major, minor, ecc) dalla PR label, e ci permette di avere pre-release in beta durante il testing
Per maggiori info sull'azione o su i parametri che si possono modificare attraverso il commit message vedere: https://github.com/marketplace/actions/tag-release-on-push-action
Altre modifiche non fuzionali:
- il codice segue ora lo style format usato nella codebase di HA
- ordinati import seguendole specifiche di HA
- correzioni minori nella forma di alcune funzioni, parametri
Changes description:
- PunData holds the list of values for every pun band (retrieved from xml)
- Fascia Enumerates the bands Universally in the code
- PunValues holds the dict of current values for the sensors, this way they are bonded to the enum definition and we can get type checking errors
Files:
Coordinator:
- replaced old for loop with dynamic one using the enum value to set and get pun values, simplified the check and setup of F23
- Removed number of values per pun as a separate dictionary, using len() when needed
Interfaces:
- New file, created Enum and Interfaces nedeed
Sensor:
- replace old static creation with a dynamic loop based on Enum Fascia, this way we can add Bands without having to edit all the various reference
- Replaced definition of self.tipo with self.fascia using
Enum
- Simplified handle_coordinator_update using enum
Utils:
- Updated definitions and type return to Enum Fascia
- Updated return type of exctract_xml to match PunData type
- simplified append match statement with dynamic match
Intanto grazie! Rispondo ad un po' di punti.
Ho quindi migrato parte del programma a una struttura OOP implementando Interfacce per poter definire le strutture di dati e rendere il check e la modifica delle stesse piu' semplice e intuitivo.
Mi devi lasciare un po' di tempo per studiare le modifiche prima di approvare tutto in un colpo, perché non sono poche... E devo anche capire se riesco a interpretarle corretamente essendo nuovo di Python.
Semplificato Retry timer in caso di errore di connessione
Questo vorrei lo lasciassi com'era - se non ti scoccia - perché anch'io all'inizio volevo farlo a cicli di "n" minuti senza rompermi più di tanto. Poi però mi sono reso conto che la pagina interrogata spesso si pianta per più tempo. Quindi quel meccanismo l'avevo studiato per fare in modo che il tempo di attesa fosse breve all'inizio, per problemi ad esempio transitori di connessione e via via più lungo per riuscire a tirare fuori comunque un valore senza aspettare il giorno successivo.
Mi pareva logica la sequenza fatta: 10, 60, 120 e 180 minuti per poi desistere per la giornata.
aggiunto caso in cui lo ZIP non e' valido ma la connessione e' avvenuta con successo ( da gestire come si vuole, per ora rimanda a domani)
Utile. Userei lo stesso meccanismo di cui sopra, quindi ZIP non valido (che può avvenire credo anche se ne scarica mezzo, quindi un errore sostanzialmente di connessione) deve fare il retry come già fa ora (senza però un'eccezione distinta, proprio per quel motivo che mezzo file comunque è un errore per me).
Ho aggiunto una Github Action che Bumpa e crea una versione nelle release per ogni push/PR sul master, purtroppo per ora non sono riuscito a trovare un modo per fargli bumpare anche la versione in manifest.json, quindi abbiamo un mismatch tra le due
Ecco questa cosa volevo farla da tempo e la sto testando in locale (anche se per capire bene se funziona la devo buttare per forza qua). Se mi dai il tempo di implementare quella che ho trovato, vorrei usassimo quella. Aggiorna pure il manifest.json e anziché elencare i commit nelle release mette solo le PR.
E' consigliato utilizzare un branch e fare un PR invece che pushare sul main direttamente
Hai ragione e infatti la GitHub Action che volevo usare "obbliga" a fare questo proprio perché crea la release automaticamente una volta che si fa la PR nella master.
Tieni conto che finora non l'ho fatto perché era un progetto personale, neppure conoscevo le Actions, insomma un qualcosa per me che ho voluto pubblicare ma senza aspettarmi chissà che cosa di riscontro. Non immaginavo fosse così desiderata questa cosa dei prezzi PUN!
il codice segue ora lo style format usato nella codebase di HA ordinati import seguendole specifiche di HA, correzioni minori nella forma di alcune funzioni, parametri
Qui mi dovrai dare una mano, perché non me ne intendo molto.
Dammi solo il tempo di preparare la Action mettendo i tag anche nelle versioni precedenti (vediamo se riesco a fare casino) e magari se puoi sistemare quelle due cosette qui sopra ti ringrazio.
P.S.: Ah, direi poi di usare l'italiano anche per le modifiche e i commenti, visto che questo progetto per sua natura è italiano e non ha senso esportarlo in altre nazioni (che se ne fanno del nostro PUN? 😄).
P.P.S.: Sono riuscito a capire come fare quanto avevo scritto QUI e pare sia possibile!
Ciao, allora, tranquillo per le changes, prenditi il tempo che ti serve e se hai dubbi chiedimi pure, ho fatto la draft apposta!
Questo vorrei lo lasciassi com'era - se non ti scoccia - perché anch'io all'inizio volevo farlo a cicli di "n" minuti senza rompermi più di tanto. Poi però mi sono reso conto che la pagina interrogata spesso si pianta per più tempo. Quindi quel meccanismo l'avevo studiato per fare in modo che il tempo di attesa fosse breve all'inizio, per problemi ad esempio transitori di connessione e via via più lungo per riuscire a tirare fuori comunque un valore senza aspettare il giorno successivo.
Mi pareva logica la sequenza fatta: 10, 60, 120 e 180 minuti per poi desistere per la giornata.
in teoria posso modificare il timer per farlo combaciare con i vecchi tempi, non sapevo del fatto che il sito desse problemi cosi importanti, magari quello nuovo sara' meglio, comunque nel caso preferissi proprio la vecchia forma lo rispristino no problem.
Utile. Userei lo stesso meccanismo di cui sopra, quindi ZIP non valido (che può avvenire credo anche se ne scarica mezzo, quindi un errore sostanzialmente di connessione) deve fare il retry come già fa ora (senza però un'eccezione distinta, proprio per quel motivo che mezzo file comunque è un errore per me).
Per il fattore ZIP si alla fine non cambia molto, li ho divisi piu' che altro per avere un errore concreto nel momento in cui l'API ritornasse qualche errore di auth o cose simili, in modo da avere un avviso piu' preciso, effettivamente uno zip non valido non e' molto diverso da un errore generico, implemento la change e metto la logica normale anche in questo caso.
Ecco questa cosa volevo farla da tempo e la sto testando in locale (anche se per capire bene se funziona la devo buttare per forza qua). Se mi dai il tempo di implementare quella che ho trovato, vorrei usassimo quella. Aggiorna pure il manifest.json e anziché elencare i commit nelle release mette solo le PR.
per le actions assolutamente, tolgo la mia, se vuoi fare un branch e fare una draft se mi metti come collaboratore magari posso darti una mano :)
ps. ho aggiunto un badge nel readme per pescare l'ultima versione ;)
per il format style usando vscode e ereditando l'env di HA ha gia' linter ecc settati, nel caso ti posso spiegare come impostarlo 👍
Per l'italiano si perdonami ho iniziato in italiano poi mi sono perso, e' l'abitudine, cerco di mantenere l'italiano 😅
Si avevo cercato qualcosa e avevo mezzo provato ad aggiungere la selezione del sensore di energia dalla config ma ho pensato che gia' questo era un cambiamento abbastanza grande, meglio farlo per step 😁
Non immaginavo fosse così desiderata questa cosa dei prezzi PUN!
In realta' e' tanto che uso l'integrazione e come avevo gia' detto mi ero fatto sensori ecc per calcolare le cose e volevo gia' provare a contribuire da un po', ma non avevo molto tempo per mettermi abbastanza da capire bene come funzionasse, adesso che mi sto iniziando a liberare un po' ti aiuto volentieri :)
Ciao, allora, tranquillo per le changes, prenditi il tempo che ti serve e se hai dubbi chiedimi pure, ho fatto la draft apposta!
Ottimo!
in teoria posso modificare il timer per farlo combaciare con i vecchi tempi, non sapevo del fatto che il sito desse problemi cosi importanti
Facendo i test avevo visto questa cosa, non gli piace ricevere troppe richieste quando non va. Delle volte succede anche nelle ore serali, trovo nel log il fatto che ha mancato il primo download e poi anche il secondo; per questo avere i tempi più "larghi" di solito aiuta ad avere un prezzo aggiornato al giorno.
magari quello nuovo sara' meglio
Lo spero, dopotutto era difficile fare peggio 😄
Per il fattore ZIP si alla fine non cambia molto, li ho divisi piu' che altro per avere un errore concreto nel momento in cui l'API ritornasse qualche errore di auth o cose simili, in modo da avere un avviso piu' preciso
Direi di mantere questa divisione, l'importante è che riprovi a tirare giù tutto poi, con la stessa logica di retry di prima.
per le actions assolutamente, tolgo la mia, se vuoi fare un branch e fare una draft se mi metti come collaboratore magari posso darti una mano :)
Intendi fare una branch e mettere lì i file di configurazione dell'Action di GitHub?
ps. ho aggiunto un badge nel readme per pescare l'ultima versione ;)
👍
per il format style usando vscode e ereditando l'env di HA ha gia' linter ecc settati, nel caso ti posso spiegare come impostarlo 👍
Fai te che per scrivere/testare l'ambiente usavo VSCode dentro una VM Ubuntu messa su velocemente solo per fare quello. Però non sono mai riuscito a sfruttare il linter, forse perché non ho scaricato tutta la build di HA Core, io volevo solo fare l'integrazione e quindi quello che consigliano loro:
python3 -m script.scaffold integration
non mi funzionava perché non avevo appunto tutto il pacchetto. E le modifiche le ho sempre fatte lì perché ho visto che si riesce a saltare di versione più velocemente che con Docker (che invece uso in produzione, sul QNAP).
Per l'italiano si perdonami ho iniziato in italiano poi mi sono perso, e' l'abitudine, cerco di mantenere l'italiano 😅
Anch'io negli altri progetti 😃 (commento sempre in inglese anche nei miei file personali) ma qui visto che possiamo teniamo 🇮🇹 .
Si avevo cercato qualcosa e avevo mezzo provato ad aggiungere la selezione del sensore di energia dalla config ma ho pensato che gia' questo era un cambiamento abbastanza grande, meglio farlo per step 😁
Assolutamente, questo per la versione 2 o 3. Al momento sistemiamo quello che c'è, anche perché a parte il "core" di calcolo la parte noiosa è fare la Config UI, non volevo renderla troppo difficile. Ma vedremo in futuro.
ma non avevo molto tempo per mettermi abbastanza da capire bene come funzionasse, adesso che mi sto iniziando a liberare un po' ti aiuto volentieri :)
Grazie, il tempo è sempre la risorsa più scarsa in assoluto anche perché io ho la tendenza ad aprire molti progetti e a chiuderne nessuno, ecco perché questo è così scarno. Almeno funziona 👍 e come dice il mio capo quello che non c'è non si rompe! Certo però come ho scritto nel README gli sviluppatori di HA fanno di tutto per rompere quello che funziona e devo ammettere che un po' mi dà fastidio (ma sono sicuro che s'era capito...).
per questo avere i tempi più "larghi" di solito aiuta ad avere un prezzo aggiornato al giorno.
Va benissimo allora allungo i tempi come prima no prob.
Direi di mantere questa divisione, l'importante è che riprovi a tirare giù tutto poi, con la stessa logica di retry di prima.
Top, correggo!
Intendi fare una branch e mettere lì i file di configurazione dell'Action di GitHub?
Si volendo si altrimenti in teoria puoi pushare le tue modifiche direttamente in questa draft, dovrei averti dato permesso di modifica, pero' dipende come' a livello di codice, se e' solo l'action puoi caricarla qua almeno mergiamo tutto insieme, l'unica cosa crea prima l'ultimo tag che hai effettivamente settato a mano, cosi' l'action riprende da quella versione, possiamo anche fargli fare una pre-release per questo merge, cosi' testiamo se fa' tutto bene e possiamo farla testare a chi vuole con il canale beta, se tutto va' bene possiamo poi fare la stable che arriva a tutti.
Per i calcoli si la roba dell'UI va' pensata bene perche' sono un sacco di valori e se dobbiamo farlo bene bisogna stare attenti a validazione, possibili edge cases o tutte le possibili entita' che potrebbero gestire i valori di consumo, magari qualcuno ha il consumo totale giornaliero, alcuni solo l'attuale o chissa che altro
Comunque si ultimamente hanno fatto un bel po' di changes, pero' alla fine non posso avercela troppo, stanno facendo un lavoro del cristo e HA e' diventato veramente lo state of the art per quanto riguarda la smart home, il fatto che facciamo parte del consorzio che gestisce Matter e' clamoroso per una no-profit FOSS (considerato che anche Apple ne fa' parte) ahahahah
Fai te che per scrivere/testare l'ambiente usavo VSCode dentro una VM Ubuntu
ti capisco ahahahaha avevo iniziato cosi' la prima volta, e non ci stavo capendo nulla, poi ho realizzato che ci dev'essere un ambiente apposta ( i dev dovranno fare development quindi devono usare un env perforza ahahaha)
Se hai usato docker non dovrebbe essere difficile, con Windows hai necessariamente bisogno del WSL2 installato e attivo, docker configurato per usare il wsl (dovrebbe chiederlo in automatico quando lo installi, o nelle impostazioni puoi attivarlo) e ovviamente git
fai il fork di core, e da https://developers.home-assistant.io/docs/development_environment#developing-with-visual-studio-code--devcontainer
inserisci il link del tuo fork nel field apposta e fai apri
Ti apre automaticamente VSCode e con Docker crea la folder di hassio core su un container che puoi usare attraverso VSCode Remote, teoricamente da' l'avviso in automatico del fatto che hai creato un remote e ti chiede di connettersi.
Una volta connesso al remote puoi runnare, debuggare e editare un istanza di hassio nel container e accederci normalmente da homeassistant.local, e hai direttamente i task di development integrati su vscode. (run-safe, install deps, lint, format ecc)
Una volta che sei nel remote puoi semplicemente creare una nuova cartella nella parent del core e farci un workspace dentro, apri il workspace e cloni la repo di pun, in questo modo erediti tutti i settaggi di VSCode ma con una repo pulita, e' comodissimo perche' ruff ha tutti i quick-fix settati e fa il lint onSave quindi non devi nemmeno starci a pensare, e hai l'autocomplete!
Comunque ci mancherebbe, mi sembra il minimo che possa fare per contribuire ad un progetto che comunque uso ed e' molto piu' comodo di 1000 alternative Closed source, non avendo i milioni (neanche le centinaia ngl) da poter donare almeno aiuto in qualche modo 🤣🤣 Poi appunto, avendo maturato un po' di esperienza nella programmazione e vedendo la possibilita' di poter aiutare con un progretto che uso ho colto l'occasione, le nuove feature sono fighe e non sono nemmeno realmente complesse quindi let's go! 😁💪
Ah mi sono scordato di scrivere nel PR che abbiamo anche droppato bs4 come dependency, visto che usiamo l'API non dobbiamo piu' fare scraping 👌
se e' solo l'action puoi caricarla qua almeno mergiamo tutto insieme
Prova a dare un'occhiata, ho creato una branch feat-github-actions qui con le modifiche che vorrei applicare e ti ho impostato come collaboratore (ho fatto giusto?).
Quella action l'ho vista qui e mi piaceva molto.
Poi chiaro che magari qui non è che facciamo chissà quante PR, però alla fine il changelog è meglio scriverlo a mano.
l'unica cosa crea prima l'ultimo tag che hai effettivamente settato a mano, cosi' l'action riprende da quella versione
I tag in realtà li avevo sempre fatti (se controlli ci sono), solo che non facevo le release. Mi piacerebbe - non so se sia possibile - preparare le draft release anche dei tag precedenti, così da averle come storico. Solo che non so come si fa!
possiamo anche fargli fare una pre-release per questo merge, cosi' testiamo se fa' tutto bene e possiamo farla testare a chi vuole con il canale beta, se tutto va' bene possiamo poi fare la stable che arriva a tutti
Questo non ho (ancora) capito come si fa...
pero' alla fine non posso avercela troppo, stanno facendo un lavoro del cristo e HA e' diventato veramente lo state of the art per quanto riguarda la smart home
Vero vero, non intendevo gettare fango... però sarà perché non sono del mestiere io ma la documentazione non è proprio chiarissima. Sembra Google con Android, dove per capirci qualcosa devi guardare il sorgente!
Se hai usato docker non dovrebbe essere difficile, con Windows hai necessariamente bisogno del WSL2 installato e attivo
Ecco, non volevo usare WSL2 in Windows (e uso Docker solo nel QNAP per far girare HA).
hmmm, beh in teoria VSCode usa docker, quindi anche se lo hai sul Qnap dovrebbe farti spinnare un container nuovo di development usando Remote via SSH, pero' non ricordo bene come si fa', cerco e magari ti linko qualcosa 👌
ma la documentazione non è proprio chiarissima.
nono, e' proprio atroce per il development ahahah la parte User e' super documentata (piu' o meno) ma quella dev e' tragica.
Questo non ho (ancora) capito come si fa.
in teoria basta segnare la release come pre-release e impostare il tag con beta ed esce nel canale beta.
Si i tag avevo visto ma pensavo fossero indietro rispetto all'attuale sorry 😅
Quella action l'ho vista qui e mi piaceva molto.
precisa, il comando python era la parte che sapevo che si poteva fare ma non avevo ancora capito ahahahah per i commenti in realta' si ha piu' senso scriverli 👌
Comunque mi hai invitato come collaboratore su tutta la repo, era quello che intendevi fare? Io dicevo che potevi anche fare un push direttamente in questa PR con i change che almeno non dovevi darmi accesso a tutto. Per me non e' un problema eh, anzi mi fa' solo piacere, pero' magari volevi mettermi come collaboratore solo al branch (che non credo si possa fare) 😅
hmmm, beh in teoria VSCode usa docker, quindi anche se lo hai sul Qnap dovrebbe farti spinnare un container nuovo di development usando Remote via SSH, pero' non ricordo bene come si fa', cerco e magari ti linko qualcosa 👌
Mm questo non mi quadra, perché nel QNAP ho solo HA Core, non tutto il sistema di sviluppo con VSCode. Vista la bassa potenza non vorrei usarlo anche per sviluppare, ma neppure usare WSL2 su Windows quindi cercavo alternative. Tocca tenere la VM, mi sa.
in teoria basta segnare la release come pre-release e impostare il tag con beta ed esce nel canale beta.
Ah, figo! Mai provato finora.
Si i tag avevo visto ma pensavo fossero indietro rispetto all'attuale sorry 😅
Mancavano solo gli ultimi due (che ho aggiunto) dei quali m'ero scordato 🤦♂️
Comunque mi hai invitato come collaboratore su tutta la repo, era quello che intendevi fare?
Ecco in realtà no, però non ho capito come aggiungere un collaboratore ad una singola branch... Come dici, mi sa che non si può fare (almeno con la versione gratuita di Github).
Però ho bloccato la master richiedendo una review obbligatoria, non so se questa cosa funzioni, stiamo andando un po' troppo sul difficile per le mie conoscenze / ricerche su Google 😥
Io non vedo permessi, c'è un tutto o niente. Tecnicamente cosa puoi fare, qualsiasi cosa? Suggerimenti?
Io dicevo che potevi anche fare un push direttamente in questa PR con i change che almeno non dovevi darmi accesso a tutto.
Ah, non avevo inteso; avevo provato a mettere in pratica il primo commento dove suggerivi di aggiungerti come collaboratore, solo che appunto non ho trovato il modo di farlo ad una branch, non vedo proprio l'opzione 🤷🏻♂️
Tocca tenere la VM, mi sa
beh tecnicamente puoi fare tutto sulla VM , non ci pensavo ma per tanto cosi' installi docker sulla VM e fai la stessa roba😅
si scusami non volevo aggiungere complessita', poi github ha i suoi quirk con release ecc, sisi ho visto che le PR necessitano della review, hai fatto benissimo, io tanto non faro' PR senza prima aver fatto una draft come questa in modo da poterne discutere.
tecnicamente ho i permessi per pushare e fare branch e credo anche chiudere gli issue? non sono sicuro, per lavoro ho solo pushato o fatto PR nelle repo non mie 😅
comunque in caso ci volessimo sentire un po' meglio, per eventualmente discutere di qualche change ti lascio la mia mail principale, su questa ho meet, google chat, ecc (quella di github e' vecchia non ho linkato i servizi aggiuntivi) [email protected]
tecnicamente ho i permessi per pushare e fare branch e credo anche chiudere gli issue?
Secondo me sì.
non sono sicuro, per lavoro ho solo pushato o fatto PR nelle repo non mie 😅
Figurati se lo so io 😆, ci faremo esperienza!
Ok allora, ho tenuto la logica del timer ma ho messo i tempi come prima e incluso il caso dello zip o qualsiasi altro errore nella connesione. piu' qualche roba qua e la'
C'era altro da sistemare? te hai avuto modo di darci un occhiata? (per i commenti in inglese faccio un commit unica alla fine perche' ho seriamente problemi a switchare tra le due lingue mentre scrivo 😅 me ne rendo conto dopo le commit quando lo rileggo, piuttosto faccio un round in cui sistemo tutto, ci metto di meno 😂)
Per le action ho trovato gia' un edge case in cui bisogna stare attenti, se abbiamo un mismatch tra tag e release l'action fa' lo zip della repo allo stato dell'ultimo tag senza una release, non ne crea uno nuovo.
Se per esempio abbiamo un tag 2.0.1 ma non ce' una release corrispondente, quando mergiamo una PR invece di creare il tag 2.0.2 e fare la release di quello, fa' la release del 2.0.1 e non include i change della PR, pero' li' include nel changelog!
Quindi gia' per fare il merge di questo PR bisogna creare prima una release ufficiale, tipo 0.9.1, cosi' HACS inizia a seguire il versioning, e se facciamo una pre-release non esce se non selezioni beta.
Ma soprattuto l'action quando fa' la draft release e crea il tag, ne crea uno nuovo, invece di farti la release per l'ultimo tag senza release, che sarebbe l'ultimo che hai creato visto che non abbiamo release.
E' un po' convoluto, spero sia chiaro 😂
C'era altro da sistemare? te hai avuto modo di darci un occhiata?
Non ho ancora avuto tempo nel dettaglio, l'avevo guardato all'inizio prima che facessi la PR.
E' un po' convoluto, spero sia chiaro
Non sono sicurissimo di aver capito, però se invece è così i tag tecnicamente non lo crea il fatto di aver messo la label major/minor/patch? Quindi noi non definiamo nella PR la versione vera, ma diciamo solamente se è una major o minor. Quindi significa che non dovrebbe capitare quel problema, salvo per i tag già fatti finora... per i quali quindi dovremo creare le release a mano (vabbè lo farò non credo sia una cosa così complessa).
Dopodiché tutte le PR che verranno dopo saranno "automatiche".
Direi di procedere così, se sei d'accordo, in quest'ordine:
- [x] Fare le release a mano di una versione in sync con il master, creando lo ZIP manualmente
- [x] Se mi dai l'OK, fare il push della #46 così come sta
- [x] Sistemare #44 e fare una minor release così vediamo se funziona
- [ ] Ripulire tutte le tue commit così che riesca a leggerle più velocemente 😄 (intendo perché ci sono anche revert e cose che mi fanno incasinare la testa di sera 🤣) nella #45 e fare un major in beta con quella, così che chi vuole può testarla
Non ho ancora avuto tempo nel dettaglio, l'avevo guardato all'inizio prima che facessi la PR.
Tranqui era giusto per sapere :)
Non sono sicurissimo di aver capito, però se invece è così i tag tecnicamente non lo crea il fatto di aver messo la label major/minor/patch? Quindi noi non definiamo nella PR la versione vera, ma diciamo solamente se è una major o minor. Quindi significa che non dovrebbe capitare quel problema, salvo per i tag già fatti finora... per i quali quindi dovremo creare le release a mano (vabbè lo farò non credo sia una cosa così complessa)
Piu' o meno, non ho provato tutte le variabili, ma basta sapere che l'ultimo tag deve avere una release associata, altrimenti non sembra crearne uno nuovo (nel mio caso la differenza di tag era la stessa della label, il tag 2.0.1 esisteva gia' ma la release no, esisteva pero' la release e il tag della 2.0.0, ho fatto il merge con la label patch e invece di fare il tag e la release della 2.0.2, ha fatto la release della 2.0.1 e basta)
Per le vecchie release in realta' basta fare solo l'ultima allineata con il master, in modo che dal momento in cui fai il merge delle action inizia a creare update
Modifico la task list nel tuo commento cosi ne abbiamo una sola effettiva
Edit: Il fix per #44 hai gia' un idea? basta fare un try except sull'import e utilizzare il vecchio metodo?
Per la questione delle commit come si fa'? non ho mai fatto uno squash o un prune, tu? 🤣
Per le vecchie release in realta' basta fare solo l'ultima allineata con il master, in modo che dal momento in cui fai il merge delle action inizia a creare update
Però le volevo creare lo stesso, a mo' di storico delle funzionalità implementate.
Modifico la task list nel tuo commento cosi ne abbiamo una sola effettiva
Vedi che hai i grossi poteri! 🤣
Edit: Il fix per #44 hai gia' un idea? basta fare un try except sull'import e utilizzare il vecchio metodo?
Pensavo una di queste due, però al momento non ho avuto tempo di buttarmi su le due versioni (pre e post) per vedere come si comportano:
-
if SetupPhases is not None: -
(AwesomeVersion(HA_VERSION) >= AwesomeVersion("2024.4.0"))
Nel caso fosse vero, esegue le istruzioni come sono ora, altrimenti le vecchie (per Holidays immagino si possa semplicemente ignorare visto che in precedenza non dava errori).
Per la questione delle commit come si fa'? non ho mai fatto uno squash o un prune, tu? 🤣
L'avevo fatto solo in locale, praticamente ti esce un editor dove riordini le commit e puoi decidere quali raggruppare (ovviamente tu sai/ti ricordi cosa contiene ciascuna). Immagino che poi sparando su GitHub brucierà le varie commit ma non credo sia un problema. Da provare!
ah ok, provo da vscode o da gh desktop allora, thanks 👌
Pensavo una di queste due, però al momento non ho avuto tempo di buttarmi su le due versioni (pre e post) per vedere come si comportano
hmm devo provare a vedere se posso spinnare una vecchia versione con i devcontainer, non sono sicuro.
Vedi che hai i grossi poteri! 🤣
ahahahah si lo stavo copiando e ho visto che me lo faceva riordinare, a sto punto mi son detto lo scrivo li 😅
Però le volevo creare lo stesso, a mo' di storico delle funzionalità implementate.
Volendo si puo' fare uguale, pero' penso che sia meglio fare prima l'ultima release e settarla come latest, in modo che facciamo passare hacs alle release e tag, poi fare le vecchie stando attenti a deflaggare il setta come latest, cosi' evitiamo che magari nel momento in cui si crea per esempio la v0.4 anche chi e' sul main riceve un update che e' effettivamente un downgrade 😂
hmm devo provare a vedere se posso spinnare una vecchia versione con i devcontainer, non sono sicuro.
Con il metodo che usavo nella VM Ubuntu si può, ed è quello descritto nella documentazione che però non è il devcontainer.
Però le volevo creare lo stesso, a mo' di storico delle funzionalità implementate.
Volendo si puo' fare uguale, pero' penso che sia meglio fare prima l'ultima release e settarla come latest, in modo che facciamo passare hacs alle release e tag
Bene, approvato 👍
poi fare le vecchie stando attenti a deflaggare il setta come latest, cosi' evitiamo che magari nel momento in cui si crea per esempio la v0.4 anche chi e' sul main riceve un update che e' effettivamente un downgrade 😂
Ottimo 👌
Stasera vedo se riesco intanto a fare il merge della PR #46 e impostare la release, completando le prime due spunte.
Le release sono perfette, ho aggiornato ora e da' anche tutta la lista di vecchie versioni, e abbiamo anche il toggle per le versioni beta o per fare il downgrade 🎉
ho fatto un paio di tentativi di squash oggi pomeriggio, credo di essere pronto per farlo sul master ora 😂
Ok ho fatto lo squash, per i conflitti se vuoi li correggo io che l'ho gia' fatto 8 volte da stamattina 🤣🤣
per i conflitti se vuoi li correggo io che l'ho gia' fatto 8 volte da stamattina
Sì, correggi pure perché credo siano i file doppi delle GitHub Actions che vanno eliminati/resettati.
Altra curiosità mia:
Inoltre cosi' facendo e' possibile distribuire versioni beta in pre-release.
Per far uscire la pre-release bisogna necessariamente fare il merge della PR nella master, giusto? Quindi io per testarla dovrei farlo dall'ambiente di sviluppo, perché solo lì riesco velocemente a fare il checkout di una PR... o, in alternativa, far puntare ad una istanza di HA l'URL del tuo fork in HACS?
Altra curiosità mia:
Inoltre cosi' facendo e' possibile distribuire versioni beta in pre-release.
Per far uscire la pre-release bisogna necessariamente fare il merge della PR nella master, giusto? Quindi io per testarla dovrei farlo dall'ambiente di sviluppo, perché solo lì riesco velocemente a fare il checkout di una PR... o, in alternativa, far puntare ad una istanza di HA l'URL del tuo fork in HACS?
Sicuramente puoi far puntare HACS al fork, funziona tranquillamente, pero' forse si puo' anche fare da una PR? non saprei provo a controllare. Edit: Tecnicamente puoi fare la release di un branch o di una commit ma non di un PR, quindi penso che HACS dovrebbe prenderla comunque, possiamo provare a fare il merge di questa PR in un branch, fare la pre-release di quello e se tutto va bene facciamo il merge con il master. Ps. Facciamola girare un po' in beta perche' la cosa delle API pubblica a me sembra un po' una svista, e non vorrei che dopo che si vedono 800 GET al giorno la bloccano, perche' l'auth da cookie si puo' sempre fare, pero' meglio avere tempo di farlo con calma che non recuperare da un bug del genere in prod.
dovrei aver fixato tutto 👌
L'aggiornamento delle action ha rotto i badge di validazione 😂 Non me ne ero accorto minimamente, la linea da cambiare e' https://github.com/virtualdj/pun_sensor/blob/a1926751e98495d326e0a5b95b31045bed61739e/README.md?plain=1#L5
basta cambiare il link a validate.yaml, nulla di che, pero' se si pusha sul master fa' una nuova draft, lo sistemo io qua e quando facciamo il merge si sistema tutto? almeno rimetto anche il badge con l'ultima versione
L'aggiornamento delle action ha rotto i badge di validazione 😂
Cavolo è vero, mi ero scordato che avendo messo le validazioni dentro l'action unica...
basta cambiare il link a validate.yaml, nulla di che, pero' se si pusha sul master fa' una nuova draft
Prova a fare una PR dedicata solo a questo (con una label patch), secondo me dovrebbe aggiornare la draft esistente. Credo "vinca" il tag con peso maggiore (cioè il precedente, v0.9.0). Così testiamo se funziona e io mi esercito con il fare le review su qualcosa di semplice!
[](https://github.com/virtualdj/pun_sensor/actions/workflows/validate.yaml)
Ho fatto la PR aggiungendo anche il badge della versione, pero' ho paura che invece di aggiornare la draft faccia una versione nuova una volta fatto il merge, perche' comunque non crea le release ad ogni PR ma solo al merge, e se esiste una release anche in draft tecnicamente lui fa' quella dopo, ma potrei sbagliarmi
Se vogliamo fare le release ad ogni PR bisognerebbe cambiare il signal nell'action della release e aggiungergli i permessi per leggere le PR
Ho fatto la PR aggiungendo anche il badge della versione
Grazie! Stasera con calma faccio tutto, perché volevo "godermela" 😁
pero' ho paura che invece di aggiornare la draft faccia una versione nuova una volta fatto il merge, perche' comunque non crea le release ad ogni PR ma solo al merge, e se esiste una release anche in draft tecnicamente lui fa' quella dopo, ma potrei sbagliarmi
Mi hai messo il dubbio così stamattina al volo tutto via web ho provato sul repository privato di test e per fortuna ti sbagli: finché non pubblichi la release lui la aggiorna.
Avevo pubblicata la versione 2.0.0; ho fatto un merge di una PR con tag minor e ha creato una draft di 2.1.0. Poi senza pubblicarla ho fatto un'altra PR sempre con tag minor e una volta fatto il merge ha aggiornato la draft esistente (con 2 righe di cambiamenti) tenendo sempre la versione 2.1.0 (essendo entrambe le PR minor).
Perciò non dovrebbero esserci sorprese. Stasera vedremo! 🤞🏻
hmm interessante la cosa della release, hai controllato se nel file zip dei sorgenti ci sono effetivamente i change?
perche' a me l'altra volta aveva rifatto la release aggiungengo i changelog ma sia lo zip che il tag non erano stati aggiornati con le ultime commit, quindi avevo la release giusta con il changelog completo ma nello zip i sorgenti erano ancora quelli vecchi 🧐
Sembra quasi che aggiorni la release ma non il tag.
Quando fai la prima PR lui crea lo snapshot e il tag della 2.0.1 dal master, e crea la draft release, SE pero' non pubblichi la draft release prima di fare un'altra PR, lui modifica la release con i nuovi changelog, ma NON crea nuovamente lo snapshot e il tag, invece usa quello gia' esistente. In quel punto fa' casino, perche' carica i changelog dal master attuale, mentre lo zip viene creato dal tag, quindi dalla vecchia versione del master, creata con la prima PR. Almeno questo e' quello che e' successo a me.
Pero' appunto io avevo cancellato la draft prima di fare il secondo push, quindi magari succede solo in quel caso, idk. 😂
in ogni caso essendo un change puramente lato github cambia poco all'utente, tecnicamente non avrebbe nemmeno senso fare la release😂 Pero' potremmo fare la pre-release direttamente di questo e vedere se funziona, tanto per passare a un stable basta fare una release manuale o semplicemente aspettare la PR dopo, comunque valuta te come ti torna meglio stasera, tanto e' proprio l'update perfetto, praticamente non e' nemmeno un update 😂
hmm interessante la cosa della release, hai controllato se nel file zip dei sorgenti ci sono effetivamente i change?
Non posso controllare lo ZIP perché rimane una draft quindi non fa lo ZIP. Lo fa solo nel momento in cui la pubblichiamo e nel repository mio di test pareva di sì.
Sembra quasi che aggiorni la release ma non il tag.
Se clicco sui tag non c'è attualmente un tag per la 0.9.0 (la versione della draft) quindi non dovrebbe fare casino perché non l'ha neppure creato.
in ogni caso essendo un change puramente lato github cambia poco all'utente, tecnicamente non avrebbe nemmeno senso fare la release😂
tanto e' proprio l'update perfetto, praticamente non e' nemmeno un update 😂
Infatti era solo una scusa perfetta per provare.
Pero' potremmo fare la pre-release direttamente di questo e vedere se funziona, tanto per passare a un stable basta fare una release manuale o semplicemente aspettare la PR dopo
Fatta pre-release, mi pare una 💣! Ha inserito lo ZIP automaticamente e dentro il manifest ha la versione corretta. Io non vedo cose sbagliate, ma visto che avevi provato anche tu dacci un'occhiata.
Yep ho visto! anche il toggle della beta funziona, se non abiliti 'mostra beta' la 0.9 non esce 👌
si comunque sembra tutto giusto, bho magari avevo configurato male io qualcosa, o magari davvero aver cancellato la release lo ha confuso, vai a sapere 😂
L'unica cosa che a me continua a non funzionare è HACS, che nonostante abilitando le beta visualizzi la 0.9.0, poi scegliendo quella alla fine scarica sempre la 0.8.0.
Se ci vado dentro mi dice che c'è un aggiornamento alla 0.9.0, quindi clicco su update, riavvio, aggiorna ma non sembra tiri giù lo ZIP... infatti il manifest non è quello patchato (versione 0.0.0 e requirements vuoti). Azz... ora ho capito, va modificato hacs.json 🤦♂️