perl: neuer cpan Modulhersteller? lokale Konfigurationstextdateien und ausführbare Dateien auch?

8

Ich schreibe ein Perl-Programm, das ich mit anderen teilen möchte, eventuell über cpan. es kommt zu dem Punkt, an dem ich darüber in größerem Maßstab nachdenken sollte.

  • Vor zehn Jahren habe ich einmal den h2xs-Paket-Maker benutzt. Ist das immer noch der empfohlene Einstieg? Früher gab es ein paar Alternativen. weil ich mit sehr wenig Erinnerung von vorne anfange, wird an dieser Stelle alles Einfache tun.

  • Ich muss einige lange Textdateien (nicht Perl-Module) für die Konfiguration lesen. Wo gebe ich sie an und wie greife ich auf sie zu, egal wo das Modul installiert ist? (FindBin?) _DATA _ ist unbequem.

  • Ich muss eine ausführbare Datei (linux und osx) bereitstellen. kann das Einbinden einer ausführbaren Datei in den Pfad des Benutzers Teil der Modulinstallation sein? (wie?)

  • Ich würde gerne in der Lage sein, es weiter zu entwickeln, es zu Testzwecken laufen zu lassen, eine neue Version zu haben, es neu zu packen und es einfach neu zu laden.

  • vor dem Hochladen auf cpan, kann ich ein cpan-Paket zur einfachen lokalen Installation für Downloader und Tester freigeben?

    # cpan & lt; mybundle.cpanbundle

Beratung geschätzt.

Grüße,

/ iaw

    
ivo Welch 28.01.2014, 15:57
quelle

2 Antworten

5

Wenn ich irgendetwas mit Andy Lester zu sagen habe, höre ihm stattdessen zu. Er weiß mehr als ich es jemals tun werde.

  • Module :: Starter ist eine gute und einfache Methode, um Modulgerüste zu erstellen. Mein Standpunkt ist, dass es seit einigen Jahren der Standard für solche Dinge ist.

  • Für Konfigurations- / Supportdateien denke ich, dass Sie wahrscheinlich File :: ShareDir möchten. Vielleicht lohnt sich Data :: Section , wenn es nur darum geht, mehrere __DATA__ -Abschnitte zu benötigen.

  • Sie können Skripts im Unterverzeichnis bin Ihrer Distribution speichern Das Build-Tool wird es zur Installationszeit an den richtigen Platz stellen.

  • Ein Build-Tool kümmert sich um den von Ihnen beschriebenen Workflow.

  • Bündel sind etwas anderes. Sie machen eine Distribution und teilen das Tarball / Archiv.

Wenn Sie PERL5LIB entsprechend eingerichtet haben, wiederholen Sie make test , make install , make dist nach Herzenslust. Zu Entwicklungs- / Sharing-Zwecken arbeiten viele Projekte mit github oder ähnlichem - macht es einfach zu teilen. Sie haben private Konten für geschäftliche Zwecke. Sehr nützlich, wenn Sie zurückspulen und sehen möchten, wo / wann ein Problem aufgetreten ist.

Wenn Sie eine Kopie von cpanm erhalten (einfach zu installieren, ziemlich leicht), dann kann es von einer tar.gz-Datei installiert werden oder sogar direkt von einem Git-Repository. Sie können ihm auch mitteilen, dass es auf einem lokalen Verzeichnis installiert werden soll ( local :: lib kompatibel - ein anderes Dienstprogramm, das sehr nützlich ist) .

Hoffentlich ist das seit 2014 einigermaßen aktuell. Vielleicht sehen Sie Dist :: Zilla Modulentwicklung. Mein Verständnis ist, dass es am nützlichsten für diejenigen ist, die eine große Familie von CPAN-Distributionen verwalten. Oh - wenn Sie (oder andere Leser) sich dessen nicht bewusst sind, schauen Sie sich Autodie und Try::Tiny um Fehler und Ausnahmen, Moose (für ein objektorientiertes Framework mit vollem Funktionsumfang) und Moo (für eine kleinere Lightweight-Version).

Ich denke, dass dieser Rat durchaus nicht kontrovers ist. Ich finde cpanm viel angenehmer als den "vollen" cpan client, und Moo scheint auch heutzutage ziemlich populär zu sein.

    
Richard Huxton 28.01.2014 21:50
quelle
4

Werfen Sie einen Blick auf Module :: Starter und seinen viel leistungsfähigeren (und komplexeren) Nachfolger Dist :: Zilla.

Was auch immer Sie tun, benutzen Sie nicht h2xs. Modul :: Starter wurde speziell erstellt, weil h2xs ein ungeeignetes Werkzeug zum Erstellen von Distributionen war.

    
Andy Lester 28.01.2014 16:54
quelle

Tags und Links