staging.inyokaproject.org

Soweit ich das gelesen habe muss man QT und GTK-Themes zusätzlich verpacken:

• https://forum.snapcraft.io/t/qt-apps-and-gtk-themes-an-investigation-with-partial-success/10513/

• https://forum.snapcraft.io/t/how-to-use-the-system-gtk-theme-via-the-gtk-common-themes-snap/6235

Axel-Erfurt schrieb:

Das Aussehen der Dialogfenster ist völlig unterschiedlich.

Ja, das liegt IMHO daran, dass in dem Snap-Paket alle Abhängigkeiten gepackt werden. Wenn ein spezifisches System-Design nicht mit paketiert wird, sieht es eben besch* aus. Nun kann man theoretisch sagen, dass man alle möglichen Qt-Designs mit einpackt – dann wird das Paket aber endlos groß, obwohl die eigentliche Applikation nur ein paar Zeilen Python sind. Von daher bin ich absolut kein Freund von Snaps. Zudem bringen die meisten Distributionen Python und pip direkt schon mit. Und mir kann keiner erzählen, dass "snap install jdlangtranslator" für den Nutzer einfacher ist, als "pip install jdlangtranslator" 😉

misterunknown schrieb:

Zudem bringen die meisten Distributionen Python und pip direkt schon mit. Und mir kann keiner erzählen, dass "snap install jdlangtranslator" für den Nutzer einfacher ist, als "pip install jdlangtranslator" 😉

👍

Warum gibt's hier keinen 'Gefällt mir' Button?

Wie man auf dem Bild auch noch sehen kann werden in der snap Version einige Ordner gar nicht angezeigt.

misterunknown schrieb:

Und mir kann keiner erzählen, dass "snap install jdlangtranslator" für den Nutzer einfacher ist, als "pip install jdlangtranslator" 😉

Da die Abhängigkeiten in dem Fall sehr überschaubar sind nicht - aber wenn da noch C-Extensions, Abhängigkeiten zu bestimmten Versionen von Modulen oder zu plattformspezifischen Besonderheiten drin stecken, die über die reguläre Paketverwaltung installiert werden müssen, sieht das schon anders aus - dazu muss der Nutzer viel mehr wissen als sich im Snap Store ein Programm auszusuchen, das er mit einem Klick installieren kann. Ein Debian-Paket zu bauen wäre da ein schöner Mittelweg, aber das muss man dann halt für jede neue Ubuntu-Version machen.

Die Rechte des Snaps für den Zugriff aufs Dateisystem sind künstlich beschränkt, was aber das Problem aus https://xkcd.com/1200/ nicht komplett verhindert...

Ich muss mich hier leider nochmal melden: Ich habe auch noch ein anderes Programm von mir nach diesem Schema verpackt. Es findet sich hier. Das hat auch problemlos funktioniert. Allerdings habe ich heute eine neue Version fertiggestellt und wollte sie als Snap packen. Dazu habe ich einfach nur die Dateien im src Ordner ersetzt und die Version in snapcraft.ymal und setup.py geupdatet. Allerdings kommt beim Versuch das Programm zu starten nur folgende Fehlermeldung:

/usr/bin/env: 'python3"': No such file or directory

Wenn ich mit snap run --shell jdreplace die Shell des Snaps öffne und dort /usr/bin/env python3 eingebe startet ganz normal der Python Interpreter. Ich habe deshalb keine Ahnung, wie der Fehler zustande kommt. Kann da vielleicht wer mit ein bisschen mehr Ahnung von Snaps drüber schauen? Die alte funktionierende Version befindet sich im Branch snap und die neue Version mit der Fehlermeldung im Branch snap-test.

Wilma456 schrieb:

Die alte funktionierende Version befindet sich im Branch snap und die neue Version mit der Fehlermeldung im Branch snap-test.

Ich sehe den Branch in https://gitlab.com/JakobDev/jdLangTranslator/-/branches nicht - bist du sicher, dass du den hochgeladen hast?

Du bist im falschen Repo. Es handelt sich um ein anderes Programm. Der Link ist im Post.

Wilma456 schrieb:

/usr/bin/env: 'python3"': No such file or directory

Da hat sich noch ein Quote eingeschlichen, irgendwo. Das solltest du entfernen, dann sollte es funktionieren.

Ich konnte leider in dem Paket keinen überflüssigen Quote finden.

Wie gehe ich eigentlich vor, wenn mein Programm mehre Codedateien hat wie z.B. hier?

Python-Dateien kannst du in der setup.py eintragen, wie das im Einzelfall geht steht in der Dokumentation zu den setuptools. Java-Anwendungen brauchen soweit ich das gelesen habe einen eigenen parts und apps Eintrag: https://snapcraft.io/docs/java-applications

Wie mache ich das eigentlich mit den Imports? Wenn ich das Programm per Terminal starte, importiere ich z.B. mit import test. Wenn es dann ein Modul ist, importiere ich mit Import .test oder import modulname.test.Gibt es eine Möglichkeit, so zu importiere, dass es im Terminal und als Modul läuft? Ich habe da jetzt nichts gefunden und alle Imports umzuschreiben stelle ich mir besonders bei großen Programmen umständlich vor.

Wenn du dem Modul eine __main__.py gibst, kannst du es mittels python -m modulname aufrufen: https://docs.python.org/3/library/__main__.html.

Relative Importe machen normalerweise nur innerhalb des selben Moduls Sinn.

Ich meinte damit, das mein Programm aus mehren Dateien besteht, die Import werden. Was muss ich machen, dass diese Imports auch im modul funktionieren?

Damit der Import eines Moduls innerhalb des selben Moduls mit vorangestelltem Modulnamen funktionieren kann, muss das Modul im PYTHONPATH sein - eine Möglichkeit wäre es in einem Virtual Environment (vgl. https://docs.python.org/3/library/venv.html) mit pip install -e . zu installieren.

Relative Importe sind innerhalb des Moduls sind auch möglich und funktionieren, wenn du das Programm mit dem schon erwähnten Ansatzt über die main.py aufrufst.