[CORE] Usage of "shutil.disk_usage()" in stat.py not supported with python < 3.3

[sandman60]

Hi,

as discussed in the KNXUF the current stat.py is causing an exception due to the fact that this routine is not supported by pyhton < 3.3. From my PoV the basis for SH.PY should be kept identical to the former PI-Image, means 3.2, and so I would suggest to handle this in an individual logic or, if possible, check the version of python as a prereq.

Cheers,
Oliver

[bmxp]

It might be possible to upgrade the PI's Python to a more recent one like Python 3.4.
But generally speaking: Which python version will be available for the next planned PI images?

[psilo909]

3.4 wäre für mich super, auf Synology ist das etwas ätzend mit anderen Python Versionen und auf 3.4 habe ich sh.py wenigstens lauffähig hinbekommen

[cstrassburg]

Ich hab zwar die Abfrage eingebaut, aber eigentlich ist das hier ein anderes Problem.
PI-Image aus 2013 und develop Branch, wer das macht sollte wissen was er macht und wie er sich helfen kann. z.B. apt-get update ; apt-get upgrade

Bin auch für mindestens 3.4. Eigentlich ist auch schon die 3.5.1 raus.(6. Dezember 2015)

[psilo909]

3.5 würde für mich größere Aktionen im Rahmen mehrerer Tage bedeuten, weil ich dann Python wieder irgendwie im Eigenbau für Synology kompiliert bekommen müsste. Daher wenn irgendmöglich 3.4 bitte :)

[bmxp]

Ich wäre eigentlich auch für eine stabile 3.4 als Voraussetzung.

[sandman60]

Sorry Christian, das sehe ich anders. Die meisten User sind m.E. noch auf dem Image von damals, ob nun DEV oder Master ist da nebensächlich. Bitte nicht falsch verstehen, ich will nicht an der alten 3.2 festhalten, aber ein Update auf 3.4 oder 3.5.1 nur zur Anzeige von der Disk-Usage und auch nur weil diese im Core ist... Ich weiß nicht; finde ich mit Kanonen auf Spatzen geschossen.

Anders ist es wenn wir von einem neuen Image sprechen, das aber wiederum sollte m.E. die letzte verfügbare stabile Version haben, sonst macht es irgendwie gar keinen Sinn, sorry René ;-).

Wenn wir an dem Punkt ankommen wo eine elementare Änderung ein Upgrade erfordert ist das IMHO keine Frage, aber so....

Oder gibt es außer der Diskusage noch irgendeinen Grund warum die Mindestversion höher sein sollte?

Ich denke viele Alt-User werden dann einen Weg brauchen für ein Upgrade, sei es mit Backup/Restore auf ein neues Image oder sonstwie, sonst geht m.E. die breite Akzeptanz flöten und die Leute werden auf ihrem Stand verweilen und das ganze NG wird schnell verebben...

[psilo909]

Gutes Argument um bei 3.2 zu bleiben...Es sollte schon klarerer Gründe geben.

Zudem läuft es auf 3.4 ja astrein, was also nicht fordert zwingend 3.2 zu nehmen. Andersherum aber schon.. Wie gesagt ich pers. würde mir gerne die Upgradeaufwände für Syno ersparen, ich bin aktuell gar nicht sicher, ob ich das Selberbauen eines ganzen Pythons hinkriegen würde. Hatte das wegen fehlendem Bluetooth-Supports schonmal etwas halbherzig versucht und war kläglich gescheitert.. Daher könnte ein Anheben auf > 3.4 für mich erstmal den Ausstieg bedeuten :-/

[psilo909]

Korrektur, seit DSM 6 sehe ich ein Python 3.5.1-0104 - dem Herstellerpaket hat aber ephem gefehlt und das hatte ich damals nicht hinbekommen. Daher habe ich das Community-Paket mit 3.4.1 drauf. Es sollte aber handhabbar sein, auch im 3.5.1er upgrade

[cstrassburg]

@sandman60
dass viele auf develop unterwegs sind ist schlecht. Develop ist develop. Das ist schon ein Problem würde ich sagen.
Das alte Image und die Tatsache, dass viele develop als Produktivsystem verwenden soll jetzt die Weiterentwicklung verhindern? Jetzt ist es "nur" diskusage, morgen etwas anderes.
Wir können gerne eine Supported Platform Umgebung definieren und master dagegen testen, kein Ding. Aber sich jetzt auf Python 3.2 festzulegen und dafür Workarounds zu entwickeln halte ich auch für nicht praktikabel, nur weil dafür mal ein Image existiert hat. Nächste Woche kommt jemand mit ner noch älteren Version um die Ecke und dann?
Die 3.5.1 war auch nur als Bespiel gemeint
Wir können natürlich auch die 3.2 als default festlegen, ich bekomme zwar keine Pakete für mein OS mehr dafür aber ist dann mein Problem mir ne Umgebung zusammenzubasteln...

[ohinckel]

Ich sehe das eher wie @cstrassburg: wir muessen frueher oder spaeter auf neuere Versionen umstellen. Je frueher desto besser - eigentlich. Nur so kann man solche Upgrades ohne viel umstellen zu muesesn bewaeltigen. Macht man es spaeter hat man evtl. mehr Versionsunterschiede, die man so auf die schnelle nicht beheben kann. Eine stetige Migration auf aktuelle Versionen wuerde ich daher bevorzugen.

Und ja, develop ist develop: entweder man weiss was "develop" heisst, oder man verwendet die entsprechenden Releases bzw. stabile Versionen.

[sandman60]

@cstrassburg: Du sprichst nun aber ein ganz anderes Thema an, nämlich auf welcher Umgebung entwickeln die meisten Entwickler und das wäre für mich schon wieder ein ganz anderes Argument, denn hier würde eine künstliche Aufrechterhaltung eines Status Quo zu einer unnötigen Mehrbelastung führen, insb. da alle hier für Lau arbeiten. Da ich kein Entwickler bin folge ich der Entscheidung, dann sollte die Abstimmung IMHO aber in diese Richtung laufen wer auf was entwickelt.

@ohinckel: Stimme Dir voll und ganz zu, daher ja auch der Hinweis von mir eine möglichst hohe Version in einer Imageversion zu verwenden und eine entsprechende Updateprozedur zu bauen, sei es bspw. ein Komplettbackup mit anschließendem Restore auf einem neuen Image. Das gibt es aber aktuell noch nicht und daher werden die ersten dann ihre Fehlermeldungen eifrig posten warum stat.py nen Fehler wirft. ... und wenn keiner was zum Develop zurückmeldet sondern nur bei sich auskommentiert oder umschreibt wird aus Dev schnell Stable, oder? :-)

[psilo909]

Also zwei Dinge:

• Ich denke es verwenden aus der Historie alle DEV aus Angst ewig von Features und Bugfixes abgeschnitten zu bleiben. Wir sollten einen Releasezeitraum einführen, dann geht die Angst evtl weg.. Ich fände es auch gut im Wiki die geänderten Kern-Features zu dokumentieren und im Fall notwendiger Migrationen die Migrationsanleitung pro Feature.
• Bitte nur max ein Python Upgrade pro Release, sonst komme ich vor zickigem Synology-Anpassen wirklich zu garnichts mehr

[cstrassburg]

Aus diesem Issue nehme ich neue Issues mit:

• Gewünscht Support für Python 3.2 und Python 3.4 Support für Python 3.2 und Python 3.4 #34
• Aufbauen einer Testumgebung für verschiedene Python Versionen mit tox Aufbauen einer Testumgebung für verschiedene Python Versionen mit tox  #35
• Plaung Releasezeitraum und Releasemanagement Planung Releasezeitraum und Releasemanagement  #36