Refactor to Interfaces and Enums

[moddroid94]

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

[virtualdj]

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!

[moddroid94]

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 :)

[virtualdj]

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...).

[moddroid94]

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! 😁💪

[moddroid94]

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 👌

[virtualdj]

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).

[moddroid94]

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) 😅

[virtualdj]

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 🤷🏻‍♂️

[moddroid94]

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) samuel.brizzi94@gmail.com

[virtualdj]

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!

[moddroid94]

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 😂

[virtualdj]

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

[moddroid94]

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? 🤣

[virtualdj]

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!

[moddroid94]

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 😂

[virtualdj]

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 👌

[virtualdj]

Stasera vedo se riesco intanto a fare il merge della PR #46 e impostare la release, completando le prime due spunte.

[moddroid94]

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 😂

[moddroid94]

Ok ho fatto lo squash, per i conflitti se vuoi li correggo io che l'ho gia' fatto 8 volte da stamattina 🤣🤣

[virtualdj]

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.

[virtualdj]

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?

[moddroid94]

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 👌

[moddroid94]

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

[virtualdj]

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!

[![Validate](https://github.com/virtualdj/pun_sensor/actions/workflows/validate.yaml/badge.svg?branch=master)](https://github.com/virtualdj/pun_sensor/actions/workflows/validate.yaml)

[moddroid94]

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

[virtualdj]

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! 🤞🏻

[moddroid94]

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 😂

[virtualdj]

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.

[moddroid94]

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 😂

[virtualdj]

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 🤦‍♂️

[moddroid94]

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 🤦‍♂️

che strano, sta cosa a me non la fa', sto provando ad aggiornare ora alla 0.9 ma anche ieri non aveva dato problemi Edit: ha aggiornato senza problemi Poi non so io uso un Pi4 dedicato per HA e giro sull'ultima versione sia di OS che supervisor

come mai hacs.json? c'e' per caso qualche ref a quale zip deve scaricare? 😂

[virtualdj]

Ecco, ha fatto il casino che dicevi. La colpa è del fatto che avevo fatto la pre-release, quindi ha duplicato il tag e mi ha mangiato anche la PR #48 che mi pare non esista più 🆘

Adesso come riapplico la #48?

[virtualdj]

Anzi, ora c'è (prima non la vedevo), ma ha il tag che punta al posto sbagliato (il commit precedente).

[moddroid94]

damn ahahahah sta cosa e' da starci attenti 😂

comunque in teoria credo ti convenga fare una release manuale, crei un nuovo tag e copi il template con i nuovi change per la relase, in quel modo pushi un update aggiornato con il master e manteniamo il format del changelog

comunque dev'esserci un modo per fargli capire che anche le prelease contano, e deve pushare un nuovo tag comunque, poi cerco bene perche' nella page dell'action sul marketplace ci sono un tot di settaggi, sicuro uno fa' qualcosa del genere 😂

[virtualdj]

comunque in teoria credo ti convenga fare una release manuale, crei un nuovo tag e copi il template con i nuovi change per la relase, in quel modo pushi un update aggiornato con il master e manteniamo il format del changelog

Infatti ho fatto così, non c'era altro verso! Che 🏐⚾🥎🏀

Perciò d'ora in poi: mai fare pre-release se non si è sicuri! Il problema è che non si può testare in HA senza pre-release 😠

comunque dev'esserci un modo per fargli capire che anche le prelease contano, e deve pushare un nuovo tag comunque, poi cerco bene perche' nella page dell'action sul marketplace ci sono un tot di settaggi, sicuro uno fa' qualcosa del genere

Forse bisogna cercare qualcosa che lanci la release alla creazione di un tag? Anche una volta associato il 0.9.1 ho dovuto fare tutto a mano... Non lo so. Però dico che è una scocciatura che non gestisca le pre-release. Nel progetto da cui mi sono ispirato utilizzano le pre-release come beta-1, beta-2, ecc. magari è quella la via di uscita?

[moddroid94]

comunque in teoria credo ti convenga fare una release manuale, crei un nuovo tag e copi il template con i nuovi change per la relase, in quel modo pushi un update aggiornato con il master e manteniamo il format del changelog

Infatti ho fatto così, non c'era altro verso! Che 🏐⚾🥎🏀

Perciò d'ora in poi: mai fare pre-release se non si è sicuri! Il problema è che non si può testare in HA senza pre-release 😠

comunque dev'esserci un modo per fargli capire che anche le prelease contano, e deve pushare un nuovo tag comunque, poi cerco bene perche' nella page dell'action sul marketplace ci sono un tot di settaggi, sicuro uno fa' qualcosa del genere

Forse bisogna cercare qualcosa che lanci la release alla creazione di un tag? Anche una volta associato il 0.9.1 ho dovuto fare tutto a mano... Non lo so. Però dico che è una scocciatura che non gestisca le pre-release. Nel progetto da cui mi sono ispirato utilizzano le pre-release come beta-1, beta-2, ecc. magari è quella la via di uscita?

potrebbe essere che effettivamente usare il semantic giusto cambi qualcosa, ma non sono sicuro, magari ce' un flag per fargli calcolare anche quelle

comunque in realta' le pre si possono fare, solo che se siamo in beta non possiamo fixare la stable, prima di fare qualsiasi cosa dobbiamo rendere la pre una stable, cosi' l'action crea il tag invece di fare casino con le release

Per esempio: prima di fare il merge di questa PR, facciamo diventare la pre 0.9.1 una stable, se si puo', altrimenti facciamo la 0.9.2 stable dalla pre, e poi quando si fa' il merge di questa PR la release/tag che crea l'azione la mettiamo come pre.

abbiamo dei problemi se vogliamo fare un hot fix prima di integrare la pre, perche' a quel punto sei bloccato con la pre, finche non la rendi stable.

per farlo 'bene' dovremmo usare un branch apposito per le beta, cosi' per le pre usiamo come target il branch beta, e quando abbiamo finito il testing mergiamo il branch nel master e facciamo solo stable da quello. in questo modo possiamo fare hotfix/patch sul master mentre testiamo il beta, e possiamo fare hotfix e pre-release separati sul beta quando serve

[virtualdj]

Per esempio: prima di fare il merge di questa PR, facciamo diventare la pre 0.9.1 una stable, se si puo', altrimenti facciamo la 0.9.2 stable dalla pre, e poi quando si fa' il merge di questa PR la release/tag che crea l'azione la mettiamo come pre.

Non mi pare una buona scelta, questa. Se è una pre, deve restare pre. Meglio piuttosto le beta a questo punto.

abbiamo dei problemi se vogliamo fare un hot fix prima di integrare la pre, perche' a quel punto sei bloccato con la pre, finche non la rendi stable.

Appunto, ma la pre deve rimanere beta, non può essere stabile solo per fare l'hotfix secondo me.

per farlo 'bene' dovremmo usare un branch apposito per le beta, cosi' per le pre usiamo come target il branch beta, e quando abbiamo finito il testing mergiamo il branch nel master e facciamo solo stable da quello. in questo modo possiamo fare hotfix/patch sul master mentre testiamo il beta, e possiamo fare hotfix e pre-release separati sul beta quando serve

Siamo sicuri che con questo sistema le release vengano fuori correttamente? Mi pare che il release-drafter.yaml controlli solo il branch master e credo sia giusto così... Infatti anche il progetto da cui l'ho preso funziona in questa maniera e gli hotfix non vengono preclusi. Mi sa che la chiave sta proprio nel semantic versioning... ma debbo studiarlo e ora ho finito il tempo. 😉

[moddroid94]

Non mi pare una buona scelta, questa. Se è una pre, deve restare pre. Meglio piuttosto le beta a questo punto.

Si bho se la pre risulta stabile comunque si puo' sempre fare un bump e chiamarla stable, non e' una pratica cosi' rara nell'ambito 😂

Siamo sicuri che con questo sistema le release vengano fuori correttamente? Mi pare che il release-drafter.yaml controlli solo il branch master e credo sia giusto così... Infatti anche il progetto da cui l'ho preso funziona in questa maniera e gli hotfix non vengono preclusi. Mi sa che la chiave sta proprio nel semantic versioning... ma debbo studiarlo e ora ho finito il tempo. 😉

Ma in realta' si e no, cioe' si puo aggiungere quale e quanti branch deve controllare l'action per fare le release, pero' l'idea era di avere appunto un branch in cui si fanno le beta a mano, se vogliamo automatizzarlo possiamo usare un altro release drafter che invece ascolta solo il branch beta, ma per quante ne facciamo e proprio per la natura beta sarebbe meglio farle a mano.

il punto e' che non e' proprio possibile fare le beta e nel frattempo fixare il master se usiamo 1 solo branch, perche' se usiamo un solo branch nel momento in cui si pusha sul master una beta non e' piu' possibile modificare la stable perche' e' indietro rispetto al master.

[virtualdj]

l'idea era di avere appunto un branch in cui si fanno le beta a mano

Ah m'era sfuggito questo dettaglio, pensavi di farle a mano.

il punto e' che non e' proprio possibile fare le beta e nel frattempo fixare il master se usiamo 1 solo branch

Ma infatti anche nell'altro progetto hanno fatto un branch beta (v5.0.0) e lì hanno messo un tag chiamato v5.0.0-beta1 e pubblicato quella pre-release che è installabile da Home Assistant. Ed effettivamente l'autore della pre-release non è github-actions come le altre, quindi suppongo ciò voglia dire che l'ha fatta a mano, come dicevi.

[moddroid94]

l'idea era di avere appunto un branch in cui si fanno le beta a mano

Ah m'era sfuggito questo dettaglio, pensavi di farle a mano.

il punto e' che non e' proprio possibile fare le beta e nel frattempo fixare il master se usiamo 1 solo branch

Ma infatti anche nell'altro progetto hanno fatto un branch beta (v5.0.0) e lì hanno messo un tag chiamato v5.0.0-beta1 e pubblicato quella pre-release che è installabile da Home Assistant. Ed effettivamente l'autore della pre-release non è github-actions come le altre, quindi suppongo ciò voglia dire che l'ha fatta a mano, come dicevi.

ah non ci avevo fatto caso, allora si e' sicuramente il metodo giusto, magari ha senso farlo gia' con questo PR?

[virtualdj]

ah non ci avevo fatto caso, allora si e' sicuramente il metodo giusto, magari ha senso farlo gia' con questo PR?

Direi proprio di sì, perché:

1. Si può testare senza rompere la funzionalità del principale (vedi API non pubblica)
2. Sicuramente dovrò fare un hotfix per il discorso del bug #44

[moddroid94]

Ok perfetto, tanto ho visto che si puo' modificare il target branch della PR. Quindi basta creare un nuovo branch, tipo dev o beta, spostare il target di questa PR e facciamo il merge nel nuovo branch direttamente 👌

se vuoi creare te il branch con il nome che preferisci poi cambio il target della PR 😁

[virtualdj]

Fatta branch v2.0.0. Una volta sistemato il problema #44 vorrei rendere "stabile" quindi v1.0 la versione attuale, che essendo v0.x paiono ancora "beta".

Dopodiché la 2.0 potrebbe diventare quella con questa PR, anche se lascerei fuori la nuova API per ora, che ne pensi? Ovvero implementare Interface, Enums ma ancora con la "vecchia" API ha senso? Sono indeciso su questo.

[moddroid94]

Perfetto per il branch!

per quanto riguarda le API, tecnicamente si possono anche lasciare, ma avevo un timore, e qua ne ho avuto conferma: https://gme.mercatoelettrico.org/it-it/Home/MediaGME/ArchivioNews?id=6222

in pratica smetteranno di aggiornare il sito dal 30 settembre 2024, e lo dismettono completamente a fine anno, speravo in piu' tempo onestamente.

Quindi non so bene ma forse non conviene divergere troppo da questa stable, piu' che altro la vecchia versione diventera' completamente inutilizzabile quindi anche chi e' ancora su una vecchia versione sara' obbligato ad aggiornare, e non vorrei che introducessimo altri problemi di compatibilta', non so dimmi anche te cosa ne pensi, alla fine mancano 4 mesi, non e'pochissimo

[virtualdj]

Beh questo cambia tutto e mi fa pensare che la nuova API non può essere qualcosa di temporaneo o in test. Tanto vale allora renderla il nuovo standard (dopo un po' che la lasciamo in beta, ovviamente). 👍🏻

[moddroid94]

eh piu' che la cosa di test la mia preoccupazione e' che possano imlpementare un auth, non so se ha senso giocare d'anticipo e provare a fargli fare una 'falsa auth' per prepararlo nel caso la inserissero, altrimenti provare a chiedergli effettivamente l'accesso ai dati direttamente da FTP, o anche solo provare a scrivergli e chiedere informazioni riguardo la disponibilita' di dati pubblici dal sito

Cioe' i dati li recuperiamo comunque, che sia XML, che sia l'excel o quant'altro, pero' se ci fosse un effettiva collaborazione sarebbe mille volte meglio, anche perche' non sappiamo nemmeno a cosa e' destinata questa API, non ce' documentazione ne nulla, ho visto che c'e' un altra API, usata in un altra parta del sito ma che recupera gli stessi dati , che pero' e' protetta correttamente.

il mio grosso dubbio e' che nel vecchio form eri obbligato a accettare il form prima di scaricare i dati, mentre nel sito nuovo e' un pop-up sul frontend, quindi non abbiamo accetazione via API, che e' giusto. Ma almeno un check del token dovbrebbero farlo, considerato che i campi nell'header ci sono (csrf token e validation mi sembra), e il download dei dati dovrebbe comunque essere sottoposto ad accettazione.

A tal riguardo ho provato a cercare documentazioni sull'uso del sito e delle sue funzionalita', alla fine offre servizi di mercato, dovra' avere documentazione, difatti ho trovato la documentazione su login e funzionalita' del sito, e' per la vecchia versione, ma magari usano dei sistemi simili o ci sono dati utili: il pdf: https://www.mercatoelettrico.org/it/MenuBiblioteca/Documenti/20040227WebServices.pdf

inoltre ho trovato un wrapper per il recupero dei dati dal sito, che potrebbe essere molto utile per prendere spunto sull'auth o sul come rendere piu' 'modulare' questa integrazione, e' in python ed e' seguito da un italiano, sadly l'ultimo update e' dell'anno scorso, ovviamente anche questo fa' capo al sito vecchio, pero invece di usare il tuo metodo implementa quelle che sembrano effettivamente delle API e gia' recupera i dati dei prezzi zonali (non c'e scritto ma dal codice si vede) la repo: https://github.com/darcato/mercati-energetici

comunque intanto inizio ad aprire effettivamente questa PR, cosi' la rendiamo pubblica se qualcuno ha qualcosa da aggiungere/suggerire

[virtualdj]

la mia preoccupazione e' che possano imlpementare un auth

Non mi pare che il vecchio sito abbia l'auth, solo il form da accettare, che non trovo nel nuovo se non all'inizio, prima addirittura di entrare (quindi non penso che la richiesta XML venga bloccata).

non so se ha senso giocare d'anticipo e provare a fargli fare una 'falsa auth'

Per quanto visto prima, secondo me no.

altrimenti provare a chiedergli effettivamente l'accesso ai dati direttamente da FTP

Non avrebbe senso, perché li chiediamo noi a nome di chi? Ogni utente lancerebbe poi una connessione e mica possiamo mettere i dati di accesso nel codice in chiaro... I dati mi pare siano pubblici e l'XML viene usato per visualizzare il prezzo unico nel grafico del sito, quindi secondo me si deve restare su quello.

Dopotutto facciamo 1 richiesta al giorno, proabilmente meno di quello che si fa col browser che 5 minuti fa si è impallato in quel sito che restituisce errori 400 anche solo a vederlo... Dire che è fatto male è ancora un complimento IMHO. Forse gli facciamo pure un favore che non generiamo traffico scaricando le immagini inutili e i tastoni grandi per ciechi.

anche perche' non sappiamo nemmeno a cosa e' destinata questa API

Se mi si caricasse il sito controllerei... ma non va ora. Non possiamo semplicemente recuperare l'XML usato in questa parte di pagina?

Non so se è la stessa API che hai trovato tu. È quella?

il mio grosso dubbio e' che nel vecchio form eri obbligato a accettare il form prima di scaricare i dati, mentre nel sito nuovo e' un pop-up sul frontend

E non è la stessa cosa, alla fine? Sempre una checkbox era.

Ma almeno un check del token dovbrebbero farlo, considerato che i campi nell'header ci sono (csrf token e validation mi sembra), e il download dei dati dovrebbe comunque essere sottoposto ad accettazione.

Bisognerebbe provare a non accettare il popup quando si entra e vedere che succede.

ho trovato la documentazione su login e funzionalita' del sito, e' per la vecchia versione

Scorrendo velocemente (e senza farmelo riassumere da ChatGPT 😄) mi pare che quello si riferisca agli operatori che caricano i prezzi, a noi non interessa quello.

inoltre ho trovato un wrapper per il recupero dei dati dal sito, che potrebbe essere molto utile per prendere spunto sull'auth o sul come rendere piu' 'modulare' questa integrazione, e' in python ed e' seguito da un italiano

Però mi pare che si aggiunga inutile complessità. Ripeto: non possiamo semplicemente pescare l'XML che visualizza il grafico giornaliero del PUN in questa pagina? Dopotutto anche quello fa la stessa cosa: disegna un grafico con i prezzi orari e sono i dati che ci interessano. Nulla più, nulla meno.

[moddroid94]

Non mi pare che il vecchio sito abbia l'auth, solo il form da accettare, che non trovo nel nuovo se non all'inizio, prima addirittura di entrare (quindi non penso che la richiesta XML venga bloccata).

no ma il sito vecchio non era un API, era una semplice request a un endpoint, non che sia diverso da un API a livello di base, pero' essendo implementata in una nuova infrastruttura e' diverso a livello di funzionamento.

Non so se è la stessa API che hai trovato tu. È quella?

Non proprio, quella che ho usato io e' quella che viene chiamata dal pulsante download qua:

Non possiamo semplicemente recuperare l'XML usato in questa parte di pagina?

L'API utilizzata dal grafico e' interna quindi puo' essere chiamata solo dal sito stesso, non abbiamo modo di accederci, possiamo tecnicamente provare a recuperare i dati dalla chiamata che fa' il sito, ma sono comunque gia' filtrati a seconda di com'e' impostata la tabella, e dovremmo comunque caricare tutta la pagina prima.

Il pulsante di download non ha accettazione, ma il sito richiede l'accettazione per essere utilizzato in ogni sua parte, il pulsante di download e' incluso, e i dati all'interno anche, quindi tecnicamente dovrebbero assicurarsi che l'utente abbia accettato il check della privacy ecc, anche da una call API, pero' bho, potrebbe essere implicito in questo caso, opotrebbe essere un errore di configurazione, magari non hanno pensato che qualcuno potesse provare a fare un semplice check delle call del sito e crearne una simile abbastanza. 😂

Non avrebbe senso, perché li chiediamo noi a nome di chi? Ogni utente lancerebbe poi una connessione e mica possiamo mettere i dati di accesso nel codice in chiaro...

si su questo effetivamente hai ragione, ci avevo penasto ma effettivamente sarebbe difficile farlo bene, pero' in un mondo ideale comunicare le nostre finalita' e magari chiedere collaborazione non sarebbe male, ma sicuro ci andiamo a infilare in problemi quindi finche' funziona top 🤣

mi pare che quello si riferisca agli operatori

sisi si riferisce agli operatori, pero' i metodi di login o auth, se presenti, sono sicuramente gli stessi, ma appunto era giusto da averlo come reference qua

[virtualdj]

Non proprio, quella che ho usato io e' quella che viene chiamata dal pulsante download qua:

Il pulsante di download non ha accettazione

Mi pare ottima.

ma il sito richiede l'accettazione per essere utilizzato in ogni sua parte, il pulsante di download e' incluso, e i dati all'interno anche, quindi tecnicamente dovrebbero assicurarsi che l'utente abbia accettato il check della privacy ecc, anche da una call API, pero' bho, potrebbe essere implicito in questo caso, opotrebbe essere un errore di configurazione, magari non hanno pensato che qualcuno potesse provare a fare un semplice check delle call del sito e crearne una simile abbastanza. 😂

Tutto è possibile... e non mi pare eccelsa la qualità di quel sito, tra l'altro.

pero' in un mondo ideale comunicare le nostre finalita'

Magari si potrebbe aggiungere al README della versione 2.0.0 un bell'esonero della responsabilità. Onestamente, 1 chiamata al giorno che fa l'integrazione non mi pare che sia sfruttamento eccessivo del traffico.

[moddroid94]

Tutto è possibile... e non mi pare eccelsa la qualità di quel sito, tra l'altro.

ahahaha no e' tutto tranne che ottima, per quello sono ancora piu' propenso a pensare a un errore 🤣

pero' in un mondo ideale comunicare le nostre finalita'

Magari si potrebbe aggiungere al README della versione 2.0.0 un bell'esonero della responsabilità.

si assolutamente, tanto se poi si rompe la sistemeremo comunque, se accadra' ci penseremo 😂

Onestamente, 1 chiamata al giorno che fa l'integrazione non mi pare che sia sfruttamento eccessivo del traffico.

assolutamente no, pero' c'e' anche il fattore che la maggior parte delle integrazioni fanno l'update all'ora di default (la mia anche), quindi nelle stats del sito si vedranno ste 200 o cosa request nell'arco di 2 secondi 🤣🤣 non so quanta gente usa l'integrazione, ma se siamo tanti e non hanno ottimizzato il backend gli crashiamo il server 😂