tokudan[m] has quit [Remote host closed the connection]
sphalerit has quit [Remote host closed the connection]
musicmatze has quit [Write error: Connection reset by peer]
ma27[m] has quit [Write error: Connection reset by peer]
haslersn has quit [Remote host closed the connection]
Ox4A6F has quit [Write error: Connection reset by peer]
florianjacob has quit [Write error: Connection reset by peer]
schmittlauch[m] has quit [Write error: Connection reset by peer]
gaisseml[m]1 has quit [Remote host closed the connection]
gaisseml[m] has quit [Remote host closed the connection]
blitzclone_ has quit [Remote host closed the connection]
jonge[m] has quit [Remote host closed the connection]
sphalerit has joined #nixos-de
musicmatze has joined #nixos-de
jonge[m] has joined #nixos-de
schmittlauch[m] has joined #nixos-de
blitzclone_ has joined #nixos-de
gaisseml[m] has joined #nixos-de
florianjacob has joined #nixos-de
Ox4A6F has joined #nixos-de
gaisseml[m]1 has joined #nixos-de
tokudan[m] has joined #nixos-de
haslersn has joined #nixos-de
ma27[m] has joined #nixos-de
hmpffff has joined #nixos-de
palo1 has joined #nixos-de
palo has quit [Ping timeout: 245 seconds]
palo1 is now known as palo
hmpffff has quit [Quit: nchrrrr…]
hmpffff has joined #nixos-de
hmpffff has quit [Quit: nchrrrr…]
Chiliparrot has joined #nixos-de
hmpffff has joined #nixos-de
Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
hmpffff has quit [Quit: nchrrrr…]
hmpffff has joined #nixos-de
Synthetica has joined #nixos-de
<palo>
wie mach ich das am besten mit cabal2nix, wenn ich 2 package habe, (beide lokal) und das eine hängt von dem anderen ab?
<palo>
ich denke mal ich brauch einen default.nix pro package. aber wie bekomme ich der shell.nix beigebraucht das es das eine packet nicht im upstream gibt, sondern das es das eine dort daneben liegende ist?
<palo>
und das stück software wird auch nicht mehr geupdated
<palo>
und openapi-generator kommt auf die swagger file nicht klar :/
<jonge[m]>
das sind natuerlich keine guten neuigkeiten
<jonge[m]>
ich interessiere mich vor allem fuer python, java und C++, weil das sprachen sind die bei uns in anderen projekten bzw. von kunden verwendet werden.
<palo>
joah da sollte das kein problem sein.
<palo>
Das command line tool ist easy zu nutzen
<jonge[m]>
hast du untersucht, wie weit weg das generierte swagger file von dem ist, das openapi-generator akzeptieren wuerde?
<palo>
ich les gerade die doku von dem openapi-generator
<palo>
und eigentlich sollte swagger version 2 ja openapi version 2 sein
<jonge[m]>
laut github wurde das letzte mal vor 2 monaten auf swagger-codegen committed, wirkt also nicht so als waere das tot?
<palo>
hatte ein ref und gleichzeitig ein type definition
<palo>
das wollte er nicht
<jonge[m]>
btw noch ne andere frage zu haskell und nix: wie loest du/ihr das mit den paketversionen? einfach alles von nixpkgs verwenden und evtl noch was anderes mit custom nix exprs dazu? oder mit stackage2nix ne ganze paketliste von stackage LTS generieren?
<palo>
ich nutz cabal2nix und generiere für viele abhängigkeiten eigene package.nix files
<palo>
die ich dann local nutze
<palo>
hmm aber so langsam nerft das cabal.
<palo>
irgendwie will der nie die dependencies finden.
<palo>
in der cabal file steht safe-exeptions als dependecy, und inder shell.nix auch, und dann beim compilieren findet cabal die dependecy nicht
<jonge[m]>
ich benutze die neuen cabal commands und hab meine local cabal config leer gesetzt, damit der nicht selbst sucht.
<jonge[m]>
dann nutze ich die paketliste die aus stackage2nix rausfaellt, was super ist weil die stackage listen immer so schoen kompatibel sind.
<palo>
hmm das war so nen direnv fuckup
<jonge[m]>
ist nur unschoen dass man dann praktisch alles selbst compilen muss, wobei wir auch unseren eigenen internen binary cache haben.
<jonge[m]>
die paketlisten zu updaten ist dann auch sehr komfortabel
<palo>
ok jetzt gehts
<jonge[m]>
benutzt du denn `niv` oder aehnlich um die custom nix expr quellen zu updaten oder machst du das alles per hand?
<palo>
mit openapi-generator-cli funktionierts ganz gut
<palo>
und das resultat läuft auch
<jonge[m]>
nice
<jonge[m]>
laesst sich die swagger haskell lib orthogonal zu anderen nutzen? zur zeit generieren wir die doku noch mit servant libs und ich wuerd das in einer uebergangsphase nicht sofort rausschmeissen
<palo>
ich weis nicht was du mit orthogonal meinst
<palo>
aber du kannst auch servant server mit dem ding anscheinend erstellen.
<palo>
so ganz nach dem aproach "swagger/openapi first"
<jonge[m]>
also ich meine... wenn du deine API in einer eigenen .hs hast, kannst du die swagger sachen einfach zusaetzlich in einer anderen .hs datei die die API.hs inkludiert nutzen, oder musst du deine API vorbereiten, damit sie mit swagger geht?
<palo>
also ich mache swagger.json -> haskell-api/{bla.cabal,lib/API.hs}
<palo>
ich schreibe die swagger file und gernerier die API.hs
<jonge[m]>
oh, ich dachte das geht anders herum.
<palo>
nein anders rum ist eher scheisse
<palo>
du willst ja deine API sprachen und framework unabhängig definieren
<jonge[m]>
nun gut, wenn da schoene typen bei herauskommen, ist das gut
<palo>
jo na das openapi ist an sich nur ne typen spezifikation für APIs
<jonge[m]>
ja, die typen muss der swagger.json->API.hs generator dann natuerlich sich ausdenken
<jonge[m]>
aber wenn der das gut macht, hab ich nix dagegen.
<jonge[m]>
waer nur schade wenn dann die eleganz der haskell implementierung leidet
<palo>
na der macht das ganz gut
<jonge[m]>
meine perspektive ist die, dass von vorne herein fest steht dass der server in haskell geschrieben wird, und es dann praktisch ist, wenn client code und doku automatisch rausfaellt.
<palo>
ja das ist für spezielle fälle bestimmt ok. In der regel wird ja client und server von 2 teams gebaut, und deswegen fängste an inital eine openapi datei aufzuseten, und in ein repo zu tun. und dann können beide teams pull-requests machen. Auserdem kann das client team einfach einen testserver aufsetzten https://www.npmjs.com/package/swagger-mock-api der zwar quatsch liefert aber das wenigstens im
<palo>
richtigen format
<jonge[m]>
ja da hast du recht - wenn man das so anfaengt, wuerde ich das auch so machen.
<palo>
ich kenn das bisher nur so
<palo>
Aber nichts spricht gegen einen server der per openapi/swagger erklärt was wie er so funktionert
<jonge[m]>
noch eine andere sache: wenn das proprietaer ist, wie/wo hostet ihr euren code intern? gitlab?
<palo>
ja ich hab nen gogs
<palo>
Ich will mit ner API von jemandem reden, und der hat ne swagger file
<jonge[m]>
von gogs habe ich bisher nur gehoert. wie funktioniert da die authentifizierung beim fetchen von repos? muss hydra ja auch machen dann
<palo>
jonge[m]: ich nutz hydra nicht. versteh das ding nicht so. ich nutzt jenkins, der hat die möglichkeit credentials zu managen
<palo>
den configurier ich auch zu 99% mit nixos
<jonge[m]>
ok, ich verstehe. mit hydra bin ich an sich total gluecklich, aber man merkt dass in der community fast keiner das ganze mit gitlab private repos verwendet.
<palo>
na ich bin mit jenkins auch ganz glücklich, das darfste aber nie nie nie in der öffentlichkeit erreichbar machen
<jonge[m]>
welchen befehl rufst mit jenkins dann immer auf? `nix-build release.nix` und kopierst den output dann irgendwohin?
<palo>
das ist unterschiedlich.
<palo>
je nachdem was es so macht
<palo>
aber jenkins hat ne menge plugins um packages in irgendwelche repos zu ballern
<palo>
artifactory etc
<palo>
aber das nutz ich selten.
<palo>
ich hab z.b. sftp user auf ingolf-wagner.de und der jenkins macht dann rsync wenn eine statische website gerendert wurde auf diesen sftp user (der nichts kann auser datein in einem ordner ändern)
<palo>
Im arbeits umfeld beschäftige ich mich nie damit
<palo>
da machen das andere
<palo>
jonge[m]: hast du die hydra aufgesetzt?
<palo>
(also deine)
hmpffff has joined #nixos-de
<jonge[m]>
ja. bei hydra gefallen mir die deklarativen jobset setups sehr gut. und ich nutze auch die plugins um von pull requests automatisch jobsets zu generieren. total gut alles.
<jonge[m]>
und der server, auf dem das laeuft, ist dann automatisch binary cache fuer alle.
<jonge[m]>
das ist auch nicht wartungsintensiv.
<palo>
nice
<palo>
joah vielleicht sollte ich mir auch mal hydra anschauen
<jonge[m]>
kann ich waermstens empfehlen. die doku ist wirklich nicht so toll und dass es in perl geschrieben ist hilft mir nicht so sehr beim code lesen. aber allgemein ein super teil.
<palo>
hmm ja das mit der doku kenn ich ja langsam schon :D
<palo>
ich werds mal auf meine todo schreiben,
<palo>
vielleicht wenn wir uns rl sehen kannste mir ja mal helfen das flotter zu verstehen
<jonge[m]>
sehr gerne. nixcon dann
hmpffff has quit [Quit: nchrrrr…]
<palo>
joah da werd ich wohl nicht sein :/
<palo>
Aber ein ander mal bestimmt
<jonge[m]>
oh, schade! ich wuenschte mir manchmal dass es so ne nix-user map wie auf https://www.haskellers.com/ gaebe
<palo>
das gibts glaub ich für retiolum
<jonge[m]>
von retiolum habe ich noch nie gehoert.
<palo>
dann ping mal den lassulus an :D
<palo>
hmm das mit cabal2nix funktioniert nicht so wie es beschrieben ist.
<jonge[m]>
"The official darknet of Krebs which utilizes the Retiolum Prefix to address individual nodes." ok *das* klingt interessant...
<palo>
ich will ne shell in der ich cabal test machen kann
<palo>
aber der findet die dependencies zu dem anderen haskell packet nicht
<palo>
:D
<palo>
jo jonge[m] haste viel spass drin
<palo>
aber kein unsittlichen sachen wie menschenhandel :D
<jonge[m]>
cabal test funktioniert bei mir... aber nur mit folgender expression, moment ich such kurz
<palo>
ah ich hab das nicht in die haskellpackages getan, sondern in den global scope
<jonge[m]>
also die shell.nix enthaelt (jetzt vereinfacht, ist bei mir wegen stackage bisschen komplizierter) `pkgs.haskelPackages.shellFor { packages = [ ... ]; buildInputs = with pkgs.haskellPackages; [ cabal-install ghcid ]; }`
<jonge[m]>
damit geht cabal test und ghcid und alles.
<palo>
auch wenn dependencies nicht im upstream sind, die du brauchst?
<palo>
ah jetzt scheints zu gehehn
<jonge[m]>
oh warte ich habe noch eine sache falsch in dem code, korrektur:
<jonge[m]>
was in `p` ist kommt halt aus dem `pkgs.haskellPackages`. wenn du da mehr pakete drin haben willst, sollten die per overlay rein schaetze ich.
<palo>
na ich will ja die cabal2nix erstellen datein nutzen
<palo>
und da gibts ne abhängigkeit die ich nur lokal hbe
<jonge[m]>
bei mir sind da exakt alle drin die ich brauche, weil ich anstatt `pkgs.haskellPackages.shellFor` halt `stackLts.shellFor` benutze.
<palo>
ich machs mal fit und poste dann was ich meine
<palo>
jo nice jetzt gehts
<jonge[m]>
ok. ich vermute dass dein cabal2nix ein substitut fuer `pkgs.haskellPackages` baut das dann auch das `shellFor` attribut besitzt?
<palo>
Das hat mir damals auch zu kompliziert ausgesehen :D
<palo>
so jetzt ist alles fluffig
<palo>
jetzt kann ich mich an die client logik setzten
<jonge[m]>
nice
<jonge[m]>
ja stackage war ne grosse stufe zu erklimmen, aber jetzt ist das schon schick dass man recht painless von der einen LTS zur naechsten springen kann.
<palo>
LTS = Long time support?
<palo>
jonge[m]: ist stack auch easy in nixos zu integrieren?
<jonge[m]>
ja. https://www.stackage.org/ bietet snapshots von hackage an. bei jedem snapshot versuchen sie so viel zu bauen wie geht und alles was nicht geht wird einfach rausgeschmissen. das ist super komfortabel fuer dich, weil du dann weisst - wenn es in stackage drin ist, dann geht das mit allen anderen libs zusammen.
<palo>
I see
<jonge[m]>
jaein. ich pflege repos in denen mehrere unterprojekte drin sind (pro proj eine cabal file) und dann ist da ne stack.yaml im repo-rootfolder drin, die die ganzen projekte referenziert und sagt mit welcher stackage version das baut.
<jonge[m]>
stack kannst du dann einfach darin benutzen - aber ich baue eine stackage.nix datei aus stack2nix und committe die dann mit.
<jonge[m]>
und dann geht das alles mit nix + cabal
<palo>
jonge[m]: I see
<palo>
jonge[m]: vielleicht bist du der richtige für ein anderes thema, ... warte mal ich suche den link
Synthetica has quit [Quit: Connection closed for inactivity]
<palo>
mist gmane ist offline
<palo>
hmm kann kein weblink zu der mailinglist finden, dachte das ist alles öffentlich, etc aber gmane ist ja offline da ging das immer
<jonge[m]>
kann ich mir evtl mal angucken wenn ich deinen stand mal auschecken koennte?
<palo>
aber funktioniert nicht 100%ig
<palo>
da fehlen libs die erlaubt sind
<palo>
ich meine da fehlen Module
<palo>
ich bin mal auf dem weg zur c-base, aber jonge[m] wenn du da was findeste wäre das super.
<jonge[m]>
kann nicht versprechen dass ich heute noch dazu komme. aber ich schaue mal rein. dir noch einen schoenen abend.
<palo>
jo mach ma wie du zeit hast
<palo>
(noch ist ja sommer und zeit drausen ist geilo)
<jonge[m]>
eine frage noch... in dem repository baut die default.nix einfach. sollte die eigentlich nicht funktionieren oder sollte ich was anderes bauen?
<palo>
ja hab noch ne shell.nix
<palo>
da mach ich dann ./devault.nix {}).env
<jonge[m]>
kannst du mir schnell sagen was ich tun muss um in den fehler reinzurennen? weil `nix-shell` geht ja auch...
<palo>
ach so na der "fehler" ist das nicht alle module da sind
<jonge[m]>
ah... ich verstehe.
<palo>
und weiter noch, wie bekomme ich das ordentlich upstream. Also so das es von dem skripten in nixpkgs ordentlich verstanden wird, da wird ja viel automagisch gemacht
<jonge[m]>
`ghc-pkg list` sagt dass er `lapack-ffi` hat, aber nicht `lapack`
<jonge[m]>
upstream habe ich solche sachen auch noch nicht gekriegt
<schmittlauch[m]>
Hat hier jemand Erfahrung mit autotools dependency discovery? Hier wird "libuuid" von configure nicht gefunden, obwohl ich es in den buildInputs mitgebe. Mag mal jemand draufgucken?