Haskell Snap: Anwendungsbereitstellung und Laufzeitabhängigkeiten

Question

Reinigen des Snap-Projekt Quellverzeichnis (Entfernen von dist) macht die folgende Beschwerde:

A web handler threw an exception. Details: 
GHC error: can't find a package database at dist/package.conf.inplace 

Also, wenn ich das Quellverzeichnis reinigen nicht mehr funktioniert? Tritt das nur auf, wenn ich mit Entwicklungsflag kompiliere?

Dies bringt mich auf die Frage der Bereitstellung von Snap-Anwendung. Was rsync wir eigentlich zum Server und was sind die Laufzeitabhängigkeiten? Ich, von course, möchte nicht die gesamte Haskell-Plattform auf dem Deployment-Server installieren. Alles, was ich brauche auf dem Server ist das Projekt ausführbare Datei und die statischen Dateien wie * .tpl, * .css, etc. Ist das korrekt?

Ich kann zwei Möglichkeiten zur Bereitstellung der Anwendung sehen: Rsync die ausführbare Datei und ihre Abhängigkeiten oder erstellen Sie eine binäre Verteilung Tarball und verschieben Sie es auf den Server. Was ist die übliche Praxis?

Welche Dateien muss ich genau in das binäre Tarball- oder Rsync-Skript aufnehmen, um alle Laufzeitabhängigkeiten zu erfüllen?

Dank

Answer 1

Zuerst ja, das ist nur das Ergebnis der Modus-Entwicklung mit. Es verwendet alle Arten von Artefakten aus Ihrer Kompilierungsumgebung. (Nur so kann sichergestellt werden, dass Ihre Kompilierungsumgebung beim dynamischen Neuladen ordnungsgemäß dupliziert wird.) Wenn Sie sie entfernen, wird sie nicht mehr funktionieren.

Im Produktionsmodus sind jedoch nur die binären und statischen Ressourcen erforderlich. Nun, und welche dynamischen Bibliotheken GHC die ausführbare Datei auch verbindet. Dies ist meist nur Standard-Sachen wie libc. Die einzige, die bei Standard-Linux-Installationen manchmal fehlt, ist libgmp. Wenn Sie FFI-Code verwenden, der an andere dynamische Bibliotheken bindet, müssen Sie natürlich sicher sein, dass auch diese Bibliotheken abgedeckt sind.