Onderwerp: SPD en een voorbeeldje van Open Sores.....

Ik heb het hier al vaker gezegd, software ontwerpen is echt niet zo moeilijk.
robuuste software, echter, is een heel ander verhaal...

Ja hoor eens moet je ook luisteren. Je moet flatpak gebruiken

Maar zonder dollen. Als je zelf je SPD in Open Sores had gepubliceerd en het had toegevoegd aan de standaard Debian repository. Voor het gemak aannemende dat jou code de toets der kritiek overleeft. Dan was bij het uitbrengen van een nieuwe versie van Debian je keurig medegedeeld dat jou software gebruik maakt van verouderde bibliotheken en of je dat wilde aanpassen.
Open source is duidelijk wat anders dan leuk raak wat code schrijven voor Open Sores.

3Noreen schreef :
Zo is dat helaas niet.
Met Debian heeft het niets te maken, het speelt ook onder Windows en op de Pi 32 en 64 bit.
Github staat vol met mopperende ontwikkelaars die aiohttp/cchardet gebruiken en die nu al een half jaar om een oplossing vragen.

Baasklusje schreef :

3Noreen schreef :
Voor alle duidelijkheid:

- pas vanaf Python versie 10 wordt het een probleem, dat cchardet
- SPD wordt ontwikkeld en 'gecompileerd' met Python 9
- Onder Windows werkt SPD zoals altijd probleemloos
- op de 64 bits Pi is nu 1 keer een probleem opgetreden met aiohttp-cchardet
- dat had niet gemogen want ook daar is gewoon Python versie 9 gebruikt voor de 'compilatie'
- ergens heeft een Pi-knutselaar (aiohttp op Github?) kennelijk iets voorbarigs gedaan.

Ik snap het volkomen. Soms gaat het net fout bij die ene.. echt altijd gaat het goed behalve.. Alleen jammer dat dan de buitenwereld neigt te denken.. Ach ja. Succes met je programmaatje. Gelukkig ligt het niet aan jou. Dat is fijn voor je. Al die moeite die je er in steekt, daar mag best waardering voor uitgesproken worden.. bij deze.

Ik ben geen Python expert, maar is het niet zo dat als je SPD compileert voor Python 9, dat deze bytecode geschikt is voor de Python >=9 engine? Maar het systeem prima Python 10 kan gebruiken, maar SPD nog steeds afhankelijk is van de software bibliotheken die op het doelsysteem zijn geïnstalleerd of beschikbaar zijn?

Wellicht ligt de snelle oplossing in het gewoon includen van de missende softwarebibliotheken in de distributie van SPD. Metpyassembly zou dat mogelijk moeten zijn. Tenzij de virtual machine van Python 10 werkelijke incompatibilteiten met zich meebrengt.

De langzamere optie is juist het fijne van open source: er is niemand die je tegen houdt om die problematische dependency te forken en geschikt te maken voor Python 10. Of aiohttp te forken en aan te passen zodat deze niet meer deze dependency gaat gebruiken.

Maar als je CI/CD was ingericht voor Python 10 systemen, dan had je dit al gemerkt voor de release toch

Orange Sunset schreef :
Python is een geinterpreteerde taal (op runtime). Echt compileren (vooraf) bestaat niet.
Nieuwste is 3.11, de door SPD gebruikte 3.9 wordt nog gesupport tot oktober 2025. Lang genoeg.

SPD gebruikt 3 externe bibliotheken: aiohttp (voor de webserver), pyserial (voor serial USB) en pyttsx3 (text to speech). Van aiohttp is bekend dat daar een module in wordt gebruikt (ccharset) die niet meer werkt onder Python 3.10

De distributiefiles van SPD worden samengesteld op Github, Menno (op ZF) heeft dat gemaakt.
Er worden (naast de text-files die ook meegaan) 4 executables gemaakt: Windows, Ubuntu en Pi 32 en 64 bits.
Het bouwen van die executables gebeurt met Pyinstaller.
In zo'n executable zit alles wat nodig is:
- de juiste Python 3.9 interpreter voor het target-OS
- de 3 benodigde bibliotheken aiohttp, pyserial en pyttsx3 (en hun benodigdheden)
- de modules van SPD zelf, in bytecode, niet gecompileerd

ALs je SPD downloadt krijg je dus één complete executable, ook als je geen Python op je machientje hebt zal die keurig werken.

Het gekke was nu dat aiohttp een module gebruikt (een open sores module ) die pas bij Python 3.10 niet meer gesupport is maar die nu bij onze Zwitserse gebruiker in een executable op Pi64bit onder Python 3.9 een fout geeft: Module Not Found.
Die module wordt bij de bouw van de executable voor Pi 64 bit dus niet meer meegenomen door Pyinstaller op Github, terwijl hij nog wel mee zou moeten in een 3.9 executable.
Kennelijk doet Python 3.9 op de Pi iets anders dan Python 3.9 op Windows, want daar werkt het wel.
Maar waarom... aan Python zal het niet liggen.

Het geeft even de complexiteit weer van de open source wereld.
Het kan overal aan liggen in de hele keten....

Je gebruiker zal dat gejammer aan z'n ** roesten. Die wil gewoon de komende jaren een werkende oplossing.

Roozeblij schreef :
die heeft hij al.

Hij heeft niet Python 3.10+ draaien die stiekum gebruikt wordt?

Jumpinjack schreef :
Hij krijgt een executable met daarin de 3.9 interpreter. Kan de gebruiker zelf niet veranderen.

Toch snap ik het issue dan niet. Als alles al netjes mee gepackaged wordt door Pyinstaller dan kan het eigenlijk alleen zijn dat de dependency native spul gebruikt (buiten de Python VM) dat niet wil werken op een ARM64 omdat daar simpelweg de native code (mogelijke optimalisatie van ccharset) voor ontbreekt. Als alles puur Python zou zijn dan kan alles netjes in bytecode omgezet worden voor de Python VM en zou ik geen problemen verwachten. Maar deze hypothese kan alleen kloppen als SPD nooit op ARM64 heeft gewerkt met webserver ingeschakeld?

Maar als het zo is dat de Python engine en libraries die mee ingepakt zijn bij ARM64 afwijkt van de versie van ARM32, windows en non-ARM linux, dan is de Python distributie het probleem niet de dependency. Er wordt immers niets van het host OS gebruikt ook al staat er toevalling een python op geïnstalleerd.

Je zult het wel goed onderzocht hebben, maar het klinkt nog steeds vreemd.

Orange Sunset schreef :
Het werkte prima op de Zwitserse Pi 64bits. Tot ik een nieuwe release maakte (op Github).
Die meldde een ModuleNotFoundError.
Dus is er op Github (met Pyinstaller) iets veranderd tussen de 2 releases.

Vast wel zo idd. Op Windows werkt ook de nieuwe release probleemloos.
Het lijkt er dus op dat Pyinstaller (die de exec samenstelt) voor de Pi64 iets anders inpakt.
De enige opdracht die Pyinstaller meekrijgt is om aiohttp mee in te pakken.
Als in de aiohttp-modules voor de Pi (die zijn vast anders dan die voor Windows) iets verkeerd zit pakt Pyinstaller dat gewoon mee in.
Helaas geheel buiten onze controle.

Hmm. Kan het zijn dat versie nummers van de dependencies en python niet gelockt zijn? Wellicht is dan nog de optie om uit te zoeken wat de laatste werkende combinatie van Python en dependencies zijn en die even vastzetten (evt alleen voor ARM64?).

Dan kunnen de RPi’s met ARM64 beestjes weer verder voorlopig.

Orange Sunset schreef :
In die richting zoeken we by Github idd, dat is Menno's specialiteit
Maar nog zonder resultaat. Er lijken geen verschillen in versies van dependencies tussen de 4 builds.

Het is tot nu toe pas bij 1 ARM64 Pi opgetreden, maar daar wel reproduceerbaar.
Ze kunnen al verder:
als de fout met niet gevonden cchardet niet optreedt is er geen probleem.
Als die wel optreedt is de webserver niet gebruiken (wel jammer) de bypass.

Sores is een part of life. Het gaat vast lukken om het op te lossen. Zo niet kun je hier afreageren.

3Noreen schreef :
Vast wel. Maar het toont m.i. een zwakte van het Open Source 'systeem' aan.

- een Japanner ontwikkelt een character set detector, cchardet, die veel sneller is dan alle andere
- daar zal wel iets in gebeuren wat Python niet netjes vindt, want ccharset wordt niet meer bruikbaar vanaf Python 3.10
- de hele wereld van Pythongebruikers wordt ermee geconfronteerd.
- Voor ARM64 Pi gaat er nog iets extra's fout: het werkt al niet meer vanaf Python 3.9
- kennelijk gebeurt er iets in cchardet wat de ARM64 niet ondersteunt
- de Japanner geeft niet thuis, hij reageert niet op alle verzoeken zijn veelgebruikte cchardet aan te passen. Vermoedelijk kan dat niet, omdat Python 3.10 de illegale acties (mijn vermoeden) in cchardet sowieso niet ondersteunt.
- en dus worden overal allerlei systemen en systeempjes geconfronteerd met problemen.

zie github.com/PyYoshi/cChardet/issues voor wat details.

Tja, vervelend zoiets. Maar als het een groot probleem is, komt er vanzelf wel een oplossing, of FORK.
Altijd goed overzichtelijk.

Gelukkig is de wereld van Closed Source veel beter. Dan had een deel van het team deze legacy verborgen gehouden. Was er een fake functie voor geschreven, die met if-jes het zelfde resultaat geeft.

Als het opensource is kan je dan niet de cChardet code kopieren en bijplakken aan je eigen code?? Dan valt er een dependencie weg, en dus de foutmelding. toch???
Zou ook kunnen. Github is microsof tegenwoordig.

rooiedirk schreef :
cchardet wordt geladen (import, in python-termen) door aiohttp.
Dat kan ik niet stoppen, want ik ga niet aiohttp veranderen.
Zelf alvast importeren zal dan vast niet helpen

Baasklusje schreef :
Dat is wel de kracht van open source: je kunt het veranderen als je wilt. Je bent niet afhankelijk van jouw closed source leverancier voor support. Geen vendor lockin. Als je closed source had gebruikt had je deze optie niet eens tenzij je het zelf vanaf scratch zou hebben geschreven. Maar dat kost meer developercapaciteit en kennis, of het eindproduct mist gewoon de functionaliteit die dit benodigd.

Waarom wissel je niet van webserver library? aiohttp is niet de enige.

Orange Sunset schreef :
Dat is vermoedelijk veel meer werk dan even wachten op een vervanger voor cchardet (in aiohttp).
Die vervanger is er al lang in de laatste versie van aiohttp, de vraag is even waarom pyinstaller niet de laatste aiohttp gebruikt.

Het is een gecompliceerd stukje van SPD.
De webserver draait in een eigen asynchrone thread, want SPD moet er geen last van hebben, zeg maar.
Bovendien werkt het in 2 richtingen: je kunt vanuit de webpagina's ook opdrachten geven aan SPD.
Daar ga ik voorlopig even niet aan knutselen.
Het ccharset probleem is overzienbaar: alleen op één 64 bits Pi.

Baasklusje schreef :
Dit lijkt me geen probleem in open source, maar in de open ontwikkelomgeving. Twee verschillende dingen.