Das deutsche Python-Forum

Hallo Forum,
ich möchte hier mein Projekt "skarabäus" vorstellen.
Die Motivation des Projektes ist, dass man jemand anderem Dateien zukommen lassen möchte, sich aber nicht mit Emailquota, Instantmessengern, ftp-Zugangsdaten etc rumschlagen möchte.
Mit dem Client (pyGTK) lädt man die fragliche Datei auf den Server (Werkzeug, Jinja) hoch, und erhält eine zufällige url, die man bequem im IM oder sonstwie dem Empfänger geben kann.
Der Empfänger kann die Datei sofort anfangen herunterzuladen, auch wenn man sie gerade noch hochlädt.

Client und Server kann man hier downloaden.
http://www.flyingelephantsoftware.de/pr ... lient.html

Kritik (auch an der Seite) ist sehr willkommen.

Absolut unwichtig, aber in core.py hat die Funktion upload() alle Parameter bis auf 'filename' dokumentiert - wenn man dann nur die Doku liest wundert man sich woher upload() weiss, was es uploaden soll...

Absolut unwichtig, die 2te:

Das Skarabäus-Logo hat ne unrealistische Reflektion, aber sieht nach ner netten Idee aus

Danke für die Antworten!

Absolut unwichtig, aber in core.py hat die Funktion upload() alle Parameter bis auf 'filename' dokumentiert - wenn man dann nur die Doku liest wundert man sich woher upload() weiss, was es uploaden soll...

ja, da ist was dran. ist im aktuellen SVN kommentiert.
Uff, bei nährerer Betrachtung fällt mir auf, dass die core.py eigentlich etwas aufräumarbeit vertragen könnte...

Das Skarabäus-Logo hat ne unrealistische Reflektion

die vom unteren, linken Segment vermute ich?
Werd ich beizeiten mal überarbeiten.

Es sieht auf alle fälle sehr interessant aus. Ich werde es am Wochenende mal auf meinem Server installieren und gucken, wie es sich benutzen lässt. Ist auf alle fälle ne nette Alternative zu FTP

MfG EnTeQuAk

Auch Programme mit GTK laufen unter verschiedenen OS, wie man z.B. an The Gimp sehen kann.

mkallas hat geschrieben:Auch Programme mit GTK laufen unter verschiedenen OS, wie man z.B. an The Gimp sehen kann.

Ja, das stimmt natürlich. Allerdings bin ich bis jetzt noch nicht dazu gekommen, das so zu packetieren, dass man es unter win zum laufen bekommen würde.
Bezüglich Paketen ist meine Priorität erstmal:
PyPI (irgendwie mögen die keine umlaute im Namen, scheint mir.)
RPM
Debian/Ubuntu
Windows und andere OS

Bis ich mir Wireshark angeguckt hab, hatte ich es auch schon aufgegeben, da meine Versuche in Windows auf eine Open-Source-Typische Art Hässlich wie die Nacht waren, und ich da nicht noch Öl ins Feuer giessen wollte

keppla hat geschrieben:

mkallas hat geschrieben:Auch Programme mit GTK laufen unter verschiedenen OS, wie man z.B. an The Gimp sehen kann.

Ja, das stimmt natürlich. Allerdings bin ich bis jetzt noch nicht dazu gekommen, das so zu packetieren, dass man es unter win zum laufen bekommen würde.

Da brauchst du nichts speziell zu paketieren. GTK+-Runtime für Win32 + PyGTK und das ist alles. Was du machen kannst, ist für lesensunkundige Nutzer ein All-in-One-Paket zu schnüren.

Hallo keppla

Super Sache - Danke! Wollte kürzlich etwas ähnliches machen, hatte dazu aber keine Zeit. Werde es heute mal testen.

Leonidas hat geschrieben:

keppla hat geschrieben:

mkallas hat geschrieben:Auch Programme mit GTK laufen unter verschiedenen OS, wie man z.B. an The Gimp sehen kann.

Ja, das stimmt natürlich. Allerdings bin ich bis jetzt noch nicht dazu gekommen, das so zu packetieren, dass man es unter win zum laufen bekommen würde.

Da brauchst du nichts speziell zu paketieren. GTK+-Runtime für Win32 + PyGTK und das ist alles. Was du machen kannst, ist für lesensunkundige Nutzer ein All-in-One-Paket zu schnüren.

Am besten einen komfortablen Installer mit InnoSetup oder NSIS. Ich persönlich mag sowas ja, denn für einen Linux-Paketmanagement-verwöhnten Nutzer ist die Vorstellung, drei Installer hintereinander ausführen zu müssen für eine einzige Software ein bisschen komisch Und der normale Windows-Nutzer kommt ohne setup.exe eh nicht weit

Edit: Mich würde noch interessieren, in wie weit du den Service für andere zu öffnen gedenkst. Nicht jeder ist mit Gtk glücklich, manche bevorzugen sogar nur CLI. Eine Dokumentation zur Service-API wäre also gut, da andere so eigene Clients schreiben könnten, ohne unbedingt die Quellen lesen zu müssen.

Das setup-Skript würde ich mit setuptools neu schreiben, dann kannst du dir nämlich auch das Run-Skript sparen, da das bei der Installation automatisch angelegt werden kann. Dazu kommen noch weitere Vorteile, wie das automatische Einschließen aller relevanten Dateien in die Source-Distribution oder die Integration von Babel zur Verwaltung der gettext-Dateien.

Ich hab etwas im Setup herumgefummelt, Version 0.4.1 des servers ist nun verfügbar.
Mann, mann, das Releasen ist ja deutlich mehr Arbeit als das Programmieren, scheint mir. Ich dachte immer, das warten wäre das, was die meiste Zeit braucht...

Super Sache - Danke! Wollte kürzlich etwas ähnliches machen, hatte dazu aber keine Zeit. Werde es heute mal testen.

Ich hab mich bemüht, die Programmierung modular zu halten, vieles sollte austauschbar sein, vielleicht kannst du es dadurch nah an das heranbringen, was du programmieren wolltest.

lunar hat geschrieben:Am besten einen komfortablen Installer mit InnoSetup oder NSIS. Ich persönlich mag sowas ja, denn für einen Linux-Paketmanagement-verwöhnten Nutzer ist die Vorstellung, drei Installer hintereinander ausführen zu müssen für eine einzige Software ein bisschen komisch Und der normale Windows-Nutzer kommt ohne setup.exe eh nicht weit

An Windows mach ich mich, sobald ich mit der "einfachen" installation glücklich bin, und wenn der VMWare-Server für Hardy Heron verfügbar ist

Edit: Mich würde noch interessieren, in wie weit du den Service für andere zu öffnen gedenkst. Nicht jeder ist mit Gtk glücklich, manche bevorzugen sogar nur CLI. Eine Dokumentation zur Service-API wäre also gut, da andere so eigene Clients schreiben könnten, ohne unbedingt die Quellen lesen zu müssen.

Ich wollte das auf jeden Fall offen halten, allerdings bin ich mir noch nicht so sicher, ob die aktuelle API so der Weisheit letzter schluss ist, und da "offenheit" imho irgendwie auch "standardisiert" heist, wollte ich erst was "offizielles" veröffentlichen, wenn ich mir da sicherer bin.
zZ führt man einen http-request nach /createid?username=x&password=y&filename=z aus, der eine xml-antwort liefert, die die "fileid" und die urls, wo man die eigentliche Datei hinposten soll, wo man eine vorschau sehen kann und wo man sie runterladen kann enthlält.

Das setup-Skript würde ich mit setuptools neu schreiben, dann kannst du dir nämlich auch das Run-Skript sparen, da das bei der Installation automatisch angelegt werden kann.

Das runscript ist gleichzeitig auch die konfigurationsdatei, und die Konfiguration ist sehr offen gehalten, so dass ich es für nicht so einfach halte, da einen befehl draus zu machen.

Ich hoffe, ich hab durch die letzte Version nicht jeden vergrault, der es getestet hat. Die nicht erwähnten abhängigkeiten habe ich nun gefixed, und (so hoffe ich) einiges leichter gemacht für den Server (stand-alone-skript, z.B.).
Ich würde mich über feedback wieder freuen!

http://flyingelephantsoftware.de/projec ... erver.html
http://flyingelephantsoftware.de/projec ... lient.html