ereuse/devicehub-django
8
0
Fork 0
Code Issues 6 Pull requests 6 Packages Projects Releases Wiki Activity

upload_legacy_snapshot #40

Open
cayop wants to merge 1 commit from upload_legacy_snapshot into main
pull from: upload_legacy_snapshot
merge into: ereuse:main
Conversation 4 Commits 1 Files changed 6 +712 -9
cayop commented 2024-12-19 11:32:35 +00:00
Owner
Copy link

#39

https://farga.pangea.org/ereuse/devicehub-django/issues/39
cayop self-assigned this 2024-12-19 11:32:35 +00:00
pedro was assigned by cayop 2024-12-19 11:32:35 +00:00
cayop added 3 commits 2024-12-19 11:32:36 +00:00
pedro commented 2024-12-19 17:15:27 +00:00
Owner
Copy link

te propongo que:

  1. todas las funciones legacy empiecen por legacy_ (he visto get_legacy y set_legacy en algunos casos, pero será más fácil identificarlas todas de esa manera)
  2. cuando hay aportaciones a funciones existentes, encapsularlos en funciones legacy_

esto ayudaría a futuro, separar lo que es inxi vs legacy (incluso por algún refactor futuro quién sabe), o incluso acabar haciendo cleanup de aquí a, ejemplo, 5 años vista

qué te parece?

te propongo que: 1. todas las funciones legacy empiecen por `legacy_` (he visto get_legacy y set_legacy en algunos casos, pero será más fácil identificarlas todas de esa manera) 2. cuando hay aportaciones a funciones existentes, encapsularlos en funciones `legacy_` esto ayudaría a futuro, separar lo que es inxi vs legacy (incluso por algún refactor futuro quién sabe), o incluso acabar haciendo cleanup de aquí a, ejemplo, 5 años vista qué te parece?
cayop force-pushed upload_legacy_snapshot from 13bac41f9f to 51a7c7d119 2024-12-20 16:05:43 +00:00 Compare
cayop commented 2024-12-20 16:11:50 +00:00
Author
Owner
Copy link

He hecho una refactorización brutal de esta rama y es nueva. Viene de main asi que no debería de haber problemas.
Tienes razón con lo de poner legacy_ pero he pensado que es mejor que sea un parse totalmente nuevo si es Legacy. De esta forma no ensuciamos mucho el parse que se tiene que quedar y podremos borrar el legacy en el futuro sin mucho drama. Ahora queda mucho más limpio. Gracias por el consejo. Me ha dado un poco de trabajo pero ha valido la pena.
Her probado lo minimo. Osea:

  • snapshot legacy
  • snapshot no legacy y normal
  • snapshot como credential
  • snapshot dpp
  • snapshot dpp como credential
He hecho una refactorización brutal de esta rama y es nueva. Viene de main asi que no debería de haber problemas. Tienes razón con lo de poner legacy_ pero he pensado que es mejor que sea un parse totalmente nuevo si es Legacy. De esta forma no ensuciamos mucho el parse que se tiene que quedar y podremos borrar el legacy en el futuro sin mucho drama. Ahora queda mucho más limpio. Gracias por el consejo. Me ha dado un poco de trabajo pero ha valido la pena. Her probado lo minimo. Osea: - [x] snapshot legacy - [x] snapshot no legacy y normal - [ ] snapshot como credential - [ ] snapshot dpp - [ ] snapshot dpp como credential
pedro commented 2024-12-20 18:13:22 +00:00
Owner
Copy link

Sí!! Buenísimo, mucho mejor 👏

Desde ahí, te propongo seguir por aquí: subir versión recortada-minimalista [1] de snapshot:

  1. legacy
  2. inxi (no legacy y normal)
  3. inxi como VC (como credencial)

Con eso yo puedo hacer un script de subida de snapshots (CURL POST) que quizá podría ejecutar tanto con DPP y sin; y así, cualquier cambio de parser lo podemos cubrir para validar que no rompe lo que ya funciona; luego se puede acabar integrando en test end to end; vamos viendo. Pero me parece pertinente dejar también esto listo sino ya con este PR muy próximamente.

Y por cierto, estos snapshots también podrían venir por defecto para la demo.

Si quieres lo vemos juntas en una sesión

[1] los snapshots se van fácilmente a los 150-200 KB, la propuesta, es reducir todo aquel texto string que no usa el parser (renombrando string largísima por "etc" o "lorem ipsum" o lo que tú quieras), y toquitear los otros datos para que tampoco se correspondan con ningún equipo real

Sí!! Buenísimo, mucho mejor 👏 Desde ahí, te propongo seguir por aquí: subir versión recortada-minimalista [1] de snapshot: 1. [ ] legacy 2. [ ] inxi (no legacy y normal) 3. [ ] inxi como VC (como credencial) Con eso yo puedo hacer un script de subida de snapshots (CURL POST) que quizá podría ejecutar tanto con DPP y sin; y así, cualquier cambio de parser lo podemos cubrir para validar que no rompe lo que ya funciona; luego se puede acabar integrando en test end to end; vamos viendo. Pero me parece pertinente dejar también esto listo sino ya con este PR muy próximamente. Y por cierto, estos snapshots también podrían venir por defecto para la demo. Si quieres lo vemos juntas en una sesión [1] los snapshots se van fácilmente a los 150-200 KB, la propuesta, es reducir todo aquel texto string que no usa el parser (renombrando string largísima por "etc" o "lorem ipsum" o lo que tú quieras), y toquitear los otros datos para que tampoco se correspondan con ningún equipo real
cayop commented 2024-12-21 00:18:37 +00:00
Author
Owner
Copy link

Tambien pienso que podríamos desacoplar más el tema del parseo. Osea seguir con lo que he hecho hasta ahora pero llendo más alla.
Un punto de entrada Interfaz de programación que interactue con el sistema de forma homogenea y luego modulos de parseo que se acoplan a esta interfaz. Esto nos permitiría habilitar parseos diferentes sin tocar los demás y sin poner en riesgo a los demás. Sería más fácil para terceras personas hacer sus propios modulos de parseo y acoplarlos al sistema. No creo que me costase mucho tiempo hacerlo y vale la pena.
No apruebes por ahora este PR hasta que haga esto.

Tambien pienso que podríamos desacoplar más el tema del parseo. Osea seguir con lo que he hecho hasta ahora pero llendo más alla. Un punto de entrada Interfaz de programación que interactue con el sistema de forma homogenea y luego modulos de parseo que se acoplan a esta interfaz. Esto nos permitiría habilitar parseos diferentes sin tocar los demás y sin poner en riesgo a los demás. Sería más fácil para terceras personas hacer sus propios modulos de parseo y acoplarlos al sistema. No creo que me costase mucho tiempo hacerlo y vale la pena. No apruebes por ahora este PR hasta que haga esto.
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin upload_legacy_snapshot:upload_legacy_snapshot
git checkout upload_legacy_snapshot

Merge

Merge the changes and update on Forgejo.
git checkout main
git merge --no-ff upload_legacy_snapshot
git checkout main
git merge --ff-only upload_legacy_snapshot
git checkout upload_legacy_snapshot
git rebase main
git checkout main
git merge --no-ff upload_legacy_snapshot
git checkout main
git merge --squash upload_legacy_snapshot
git checkout main
git merge --ff-only upload_legacy_snapshot
git checkout main
git merge upload_legacy_snapshot
git push origin main
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
cayop
pedro
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: ereuse/devicehub-django#40
No description provided.
Delete branch "upload_legacy_snapshot"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?