Open jan-christiansen opened 1 year ago
Nach meiner Recherche ist es weder möglich, selbst eine Version für HLS-Plugins vozugeben, noch wird von HLS oder den Plugins fest eine Version von Ormolu vorgegeben - ich denke anhand der Dependencies wird nur eingeschränkt und beim Builden über cabal die aktuellste kompatible Version verwendet.
Dennoch ist es verwunderlich, dass die fehlende newline
nicht durch ormolu
im Editor gesetzt wird. Newlines am Ende von Textdateien sind eigentlich Standard und sollten von jeder Version gefordert werden. Zumal Ormolu überschüssige newlines
am Dateiende bis auf eine entfernt, gehe ich eher von einem Bug aus.
https://github.com/haskell-actions/run-ormolu/blob/master/CHANGELOG.md
mit der neuesten Version von der ormulo-action kann die Version explizit angegeben werden, als Defaultwert wird allerdings die letzte bekannte Version verwendet - was für unseren Fall vermutlich gar nicht so falsch klingt
Okay, offensichtlich verwendet HLS nicht die aktuellste Version von ormolu ...
Nach einigen Tests mit verschiedenen lokalen Versionen von ormolu
, die separat verwendet wurden (also ohne den HLS),
konnte ich feststellen, dass alle getesteten Versionen die newline
am Ende setzen (ohne die Extra Einstellung von vscode).
Über das HLS-ormolu-plugin kann nicht sichergestellt werden, dass a) die beiden Versionen gleich sind und b) die newline ohne quickfix
gesetzt wird.
Ich denke, die beste Lösung ist hier, z.B. in der README eine Version vorzugeben und diese in der github-action und lokal zu verwenden. Zusätzlich zur Haskell-Extension sollte dann für ormolu eine separate Extension installiert werden, um den Formatter in vscode zu integrieren. (dabei hatte ormolu
von sjurmillidahl
bei mir nicht funktioniert, aber die extension von ilyakooo0
lief einwandfrei bisher) - die bisher in der action verwendete Version 0.4.0.0
lief lokal ohne Probleme. Die neuere Version 0.5.2.0
hatte mir für das Projekt Fehler angezeigt, scheinbar aufgrund inkompatibler Versionen in der projekt .cabal
zu Ormolu.
Wir haben besprochen, dass wir noch einmal schauen, wie cabal Abhängigkeiten auflöst, um herauszufinden, ob Einfluss darauf nehmen kann, welche Version von ormolu bei der Installation von hls verwendet wird.
Außerdem soll einmal geprüft werden, welche Version von ormolu
aktuell lokal installiert ist. Dadurch soll überprüft werden, ob es neben der "richtigen" Version von ormolu
, die gewählt werden muss, noch weitere Effekte gibt, die Unterschiede verursachen. Informationen dazu, welche Version verwendet wird, müssten sich eigentlich in einer Datei wie .ghcup/db/hls/1.8.0.0
finden lassen.
Auf Linux wird 0.5.2.0
verwendet laut der Einträge in .ghcup/db/hls/1.10.0.0
Auf Windows ist der hls
-Ordner in ghcup
leer und in db
gibt es keinen hls
- also keine Information zu den verwendeten Versionen.
Die Diskrepanz, die ich beobachten konnte an einer Stelle, lag wirklich an der Version. In 0.4.0.0
(github-action, sowei lokal) hatten es auf die gleich Weise formatiert; jetzt getestet mit HLS, sowie 0.5.2.0
lokal passten zusammen. Wir könnten die action auf v9
für 0.5.2.0
anpassen, allerdings weiß ich nicht, ob das die version bei jedem ist im HLS - und wir werden wieder vor dem gleichen Problem stehen, sobald HLS wieder eine neuere Version verwendet.
Laut der https://hackage.haskell.org/package/hls-ormolu-plugin-1.0.4.0/reports/1 wurde die aktuellst Version des HLS-ormolu-Plugin auch mit der Dependency Version 0.5.2.0
gebuildet, obwohl die 0.5.3.0
zu der Zeit schon verfügbar war.
Laut Dokumentation https://cabal.readthedocs.io/en/3.10/getting-started.html#adding-dependencies wird in Einklang mit den angegebenen constraints entsprechend die latest
Version für den Build verwendet. Mich wundert hierbei dann tatsächlich, warum das ormolu-plugin 1.0.4.0
statt 0.5.3.0
die 0.5.2.0
verwendet hat.
Ich denke, wir können nicht automatisch die Versionen in Einklang bringen.
Eine Möglichkeit besteht darin, die Versionen zu überprüfen, sobald eine neue Version von HLS erscheint und entsprechend die Version der ormolu-action anpassen. -> eher unpraktisch.
Alternativ könnte man lokal die Extension so einrichten, indem man eine toolchain vorgibt und die version von hls konkret festlegt. -> eher praktikabel.
Selbst dann bleibt noch das PRoblem mit dem nicht automatischem Setzen der newline
am Ende eines Files (wie bereits erwähnt, liegt das nicht an einer Version von Ormolu, sondern einfach am plugin in hls - eine externe Anwendung von ormolu fügt diese Zeile hinzu, ebenso bei der Verwendung einer separaten Extension für VsCode zur Integration von ormolu wird die Zeile hinzugefügt)
Scheinbar müssen wir wohl mit dem Quickfix über VSCode erstmal leben und hoffen, dass die hls irgendwann eine Version bringt, die diesen "Fehler" nicht hat.
Mittlerweile passt gefühlt gar nichts mehr zusammen mit den Versionen. Es gibt immernoch Unterschiede in der Formatierung in RDF.hs
- die korrekte 0.5.2.0
(lokal sowie in der action) rückt Zeilen der Art .= "..."
einen indent tiefer ein als das HLS-ormolu das tut. Ich habe in der .ghcup/db/hls/1.10.0
verschiedene Einträge für ormolu
für die verschiedenen ghc versionen. Der Eintrag für ghc 9.0.2
(Projektversion) führt dabei 0.5.2.0
auf.
Ich kann mir überhaupt nicht mehr erklären, wie diese Unterschiede zustande kommen.
Es gibt zwei Issues im HLS-Projekt, die sich mit dieser Problematik beschäftigen.
Die Option
Insert Final Newline
ist nur ein Quickfix. In der Action wird eigentlich einfach nur Ormolu in einer bestimmten Version auf die Quelldatei angewendet. Bitte zuerst einmal prüfen, ob das wirklich so ist. Außerdem sollte in der Readme angegeben sein, welche Ormolu-Version verwendet werden soll. In der GitHub-Action wird aktuell eine feste Version von Ormolu verwendet. Ggf. ist es sinnvoll, hier eine neuere Version zu verwenden. Bitte einmal überprüfen, ob bei der Installation des Haskell-Plugins von VSCode eine Version Version von Ormolu verwendet werden kann. Meines Wissens nach, ist das nicht möglich. Dann sollte einmal evaluiert werden, ob es eine feste Regel gibt, welche Ormolu-Version bei welcher Version von HLS verwendet wird. Meines Wissens gibt es auch diese feste Abhängigkeit nicht, ich kann mich aber auch gut irren.