AutoIt Package/Module Manager

Statement zur DSGVO im Forum

Alles zur DSGVO und zur Umsetzung im Forum hier: Statement zur DSGVO (letztes Update: 30.05.2018)
  • Guten Abend,


    wie der Titel schon andeuten laesst bin ich auf der Suche nach einer brauchbaren Moeglichkeit, AutoIt UDFs besser zu verwalten. Ich bin der Meinung auch schon einmal ein Thema dazu gefunden zu haben, hier oder im englischen Forum.

    Nun finde ich aber nichts mehr dazu.

    Hat jemand von Euch evtl. einen Hinweis dazu?


    Ich persoenlich finde die Idee gut und es wuerde mit Sicherheit dem ein oder anderen helfen, zudem waeren UDFs bestimmt auch leichter zu finden denn derer gibt es ja viele.

    Was haltet Ihr davon?


    Gruss

  • Moin,


    die Seite ist mir bekannt. Ich glaube die gehoeren auch schon alle zu meiner Sammlung.

    Eine weitere, gute, Seite ist auch https://github.com/J2TEAM/awesome-AutoIt


    Wie verwaltet Ihr eurer UDFs? Kopiert Ihr die Dateien jedes mal wieder in das aktuelle Projekt? Nutzt/schreibt Ihr nur kleinere Skripte, wo sich der Aufwand nicht lohnt?

    Ist das verwalten der UDFs, aehnlich wie composer (PHP), npm (Nodejs), pip (Python) ueberhaupt ein Usecase fuer Euch oder haltet Ihr das anders?


    Gruss

  • Ich habe da reinstes Chaos. Habe einige eigene UDFs gespeichert, aber bei weitem nicht alle. Von anderen Usern habe ich verstreut über mehrere Computer/Festplatten eine Hand voll UDFs gesichert. Wenn ich was suche lade ich es zumeist neu herunter.


    Eine Zentrale Verwaltung gibt es leider nicht, soetwas müsste von irgendwem gemanaged werden und dazu ist die Community zu klein, als dass sich das lohnt.

  • Eine Zentrale Verwaltung gibt es leider nicht

    Das ist der springende Punkt.

    soetwas müsste von irgendwem gemanaged werden und dazu ist die Community zu klein, als dass sich das lohnt.

    Da gibt es sicher kleinere Communities. Es würde schon helfen, wenn man dasUDF in den Foren immer gleich speziell ausweisen würde. Aber im Endeffekt hängt es aber an Leuten, die dem Thema eine solche Bedeutung beimessen, dass sie das sammeln und pflegen wollten. An diesen Leuten fehlt es uns. (Ich gehöre auch nicht dazu).

  • Wir können ja einen Forenabschnitt "UDF" einführen, weil aktuell landen alle UDFs im "Skripte" Forum.

    Dazu noch einen Standadisierten Header:

    Code
    1. Name : Beispiel
    2. Info : Die UDF kann xyz
    3. Tags : Mathematik, Analysis, Stochastik, usw.
    4. Autor: Mars
    5. Datum: Heute
    6. Hallo Leute, ich habe hier eine kleine UDF um xyz.
    7. Anhang: zip-Archiv mit UDF-Files + UDF-Beispiel(en)

    Ich bin auch nicht so der "Manager" ich habe schon genug zu tun den Überblick über meine eigenen Sachen zu behalten ;(

  • Ich bin auch nicht so der "Manager" ich habe schon genug zu tun den Überblick über meine eigenen Sachen zu behalten

    Damit habe ich auch so meine Probleme, daher bin ich froh das ich meistens nur grob wissen muss welche welche Funktionen ich haben will und suche stumpf mit den unterschiedlichen Package managern danach.

    Ich habe viele UDFs lokal gespeichert, meistens in einem syncronisierten Ordner (OneDrive, GoogleDrive, etc.), einige fliegen aber auch in meinem Download-Ordner rum. Auf meinem Arbeitsrechner liegen wiederum auch so einiges rum, kann ich leider nicht synchronisieren (PROXY ud Firewall sagen NEIN).


    Eine generelle Anlaufstelle im Forum waere auf jeden Fall ein Anfang, ob sich da Dinge Suche nach Filtern einbauen lassen, weiss ich nicht. Zudem gilt dieser Bereich auch nur fuer die, meisten, Deutschen. Die anderen haben da wohl auch nicht so viel von.


    Ich aette a scho so einige Ideen die ich da umsetzen wuerde, stellt sich nur die Frage ob sich der Aufwand lohnt. Zum lernen natuerlich, aber kommt das dann auch an oder wird es ignoriert...




    Wenn du damit ein Forum interenen Header meinst, ist das ok, anderfalls sollte der Header aber ohne jedwede Vorgabe sein.

    Was Header und Der Gleichen angeht wuerde ich mich schon an die im AutoIt-Wiki genannten Varianten halten, etwas ungewohnt im Vergleich zu anderen, hat sich aber groesstenteils etabliert und wird ja auch von SciTE und anderen unterstuetzt.

  • Ich meinte damit eigentlich nicht den Header in der UDF selbst, sondern im Forum, sodass jemand der gewisse Funktionen sucht direkt im Startpost in den ersten Zeilen lesen kann um was die UDF geht und sie dafür nicht erst herunterladen muss.

  • Mars Da fehlte meinerseits etwas Text; ich stimme dir da zu, ein Standard-Header fuer die Forenposts macht sinn.

    Ich bezog mich nur auf die Header der UDFs, die sind natuerlich jedem selbst ueberlassen.


    Wenn es hier eine Sammelstelle geben wuerde, waere ich bereit mir die Muehe zu machen die angelegten UDF-Posts in ein System zu uebernehmen, sofern/sobald es ein solches gibt.

    Vielleicht kann man so auch einige zur Mitarbeit bewegen.


    Unabhaengig davon werde ich mich wohl mal an einen kleinen Prototypen machen, vielleicht kommt ja was sinnvolles bei raus ;)

  • Hallo zusammen,


    ich habe mir darueber ein paar Gedanken gemacht und wuerde Euch gern ein, zwei Ansaetze aufzeigen. Waere nett wenn Ihr euch das mal in Ruhe durchlest und mir sagt was Ihr davon haltet.


    Ansatz 1: Projektdatei

    Der erste Ansatz ist art Projektdatei, nennen wir sie udfm.ini.

    Ein rein fiktives Beispiel:

    Code
    1. [Project]
    2. title = Steam Backup Manager
    3. name = steam-bm
    4. repo_type = svn
    5. author = Churanos
    6. runtime_version = >=3.3.14.5
    7. [Dependencies]
    8. AspirinJunkie/JSON = *

    Dabei wird, aehnlich wie bei anderen package managers, ueber den Eintrag [Dependencies] die UDF samt Version (falls noetig/sinnvoll) eingetragen. Diese werden dann via console command herunter geladen und in ein Verzeichnis vendor innerhalb des Projekts gespeichert. In dem Hauptskript wird nur noch eine Zeile als Include eingetragen: #Include "vendor/autoload.au3". Ueber console commands wie add oder install koennen via console auch UDFs nachgeladen werden, die dann automatisch in die udfm.ini oder einer Lockdatei geschrieben werden.

    Dieser Ansatz aehnelt dem von PHP/Composer.


    Ansatz 2: Alternatives Praeprozessor Komando

    Bei diesem Ansatz wird ohne Projektdatei gearbeitet. In den AutoIt Dateien wird eine UDF mit #uses "AspirinJunkie.JSON" referenziert. Via console command werden alle *.au3 Dateien nach dieser Direktive gescannt und alle UDFs herunter geladen, gespeichert werden die Dateien wie im ersten Ansatz.

    Nun gibt es 2 weitere Moeglichkeiten:

    1. Die #uses Direktive wird gegen ein #Include ausgetauscht.
    2. Es wird wie im ersten Ansatz weiterhin eine autoload.au3 genutzt.

    Der AutoIt Compiler ignoriert die #uses Direktive daher spricht, aus meiner Sicht und um den Verwaltungsaufwand gering zu halten, die Umsetzung von Punkt 2 eher an.



    Ich hoffe Ihr koennt mir folgen. Fuer Eure Ideen, Kritik, etc. waere ich dankbar.


    Gruss

  • Da man an SCiTe oder den Au3Check und andere Tools nicht ran kommt (sowas würde Sinn machen, wenn das vom Präprozessor direkt gefressen und included wird), wäre das vielleicht eine Idee fürs ISN Autoit Studio ?

    Richtig dufte wäre, wenn man einfach #onlineInclude "Aspirinjunkie.JSON" ganz normal in die Includes schreibt und der Präprozessor beim ersten Ausführen dieser Zeile automatisch nach dem Include sucht, es herunterlät und dann normal included (und natürlich sobald es heruntergeladen ist auch die Autovervollständigung aktualisiert usw.)


    Das doofe ist, dass man als Scite Nutzer erst irgendeinen Zusatz installieren müsste (Präprozessor und geändertes Au3Check), in ISN könnte man das direkt fest verbauen.


    Aber das ist Zukunftsmusik, erstmal brauchen wir einen "UDF" Foren Abschnitt.

  • Aber das ist Zukunftsmusik, erstmal brauchen wir einen "UDF" Foren Abschnitt.

    Ich fände das auch gut. Allerdings halte ich das in diesem Zusammenhang wirklich nicht für einen entscheidenden Punkt. Einfach weil ein Großteil aller UDF, ja gar nicht aus diesem Forum kommt..

    Das heißt, man kommt wohl nie zu einem System in dem alle UDF von einem Paketmanager automatisch gefunden und aktualisiert werden können. Es müssten immer Nutzer eingreifen und ein Archiv pflegen, wie es Water und Churanos hier in Beitrag 2 und 3 verlinkt haben.

    Wenn man nun einen Paketmanager erstellen möchte scheint mir das englische Wiki als Basis eigentlich der beste Ausgangspunkt.

  • Man kann ja bei einem solchen Projekt durchaus auch mehrere Repositories pflegen. Das ähnelt ja etwas einer klassischen Linux-Paketverwaltung, da gibt es auch zig Repos.

    Mehrere Repos wuerde ich auch befuerworten, denkbar sind auch Meta-Repositories um mehrere Repos zusammen zu fassen.

    Ich versuche das Thema moeglichst verstaendlich im englischen Forum zu posten, mal sehen wie dort der Anklang dazu ist.


    /EDIT:

    Hier der Link aus dem englischen Forum, falls es jemand verfolgen moechte: https://www.autoitscript.com/f…it-packagemodule-manager/