lassulus changed the topic of #nixos-de to: Willkommen im deutschen NixOS Channel.
mbrgm_ has joined #nixos-de
mbrgm has quit [Ping timeout: 255 seconds]
mbrgm_ is now known as mbrgm
h0m1 has quit [Quit: WeeChat 2.7.1]
h0m1 has joined #nixos-de
h0m1 has quit [Ping timeout: 272 seconds]
h0m1 has joined #nixos-de
das_j has quit [Quit: killed]
ajs124 has quit [Quit: killed]
Scriptkiddi has quit [Quit: killed]
ajs124 has joined #nixos-de
Scriptkiddi has joined #nixos-de
das_j has joined #nixos-de
mbrgm has quit [Ping timeout: 240 seconds]
mbrgm has joined #nixos-de
<makefu>
jonge[m]: es ist auf jeden fall ein weg und der deckt sich so wie es aussieht mit meinem weg. kann also nicht der beschissenste weg sein
palo1 has joined #nixos-de
palo has quit [Ping timeout: 265 seconds]
palo1 is now known as palo
<jonge[m]>
:-D thx
<makefu>
ich hab das setup auch hier auf arbeit in produktion, weil es hier immer nen pain ist mit intercepting proxy und credentials und nichterreibachen netzen
<jonge[m]>
ja ich hab zuhause paar laptops und rechner rumfliegen und will die alle mit nixops remote deployen, aber ich habe keine lust bei denen allen partitionierung, formattierung usw. usf. per hand zu machen. und wlan passwort haendisch eintragen... vpn einrichten... das darf mir alles der offline-installer abfruehstuecken
<jonge[m]>
und dann ist es weniger aufwand sich eine kleine ghetto-buildfarm zu bauen
<fionera>
wenn ich `nixos-rebuild build -I nixpkgs=.` mache, läd er jedes mal aufs neue alles vom cache. mache ich was falsch?
<fionera>
Ich versuche gerade Sway zu overriden damit es auf master compiled und nicht 1.4, da dort recht viele bugs behoben wurden
<lassulus>
worauf zeigt denn nixpkgs?
woffs has quit [*.net *.split]
wirew0rm has quit [*.net *.split]
schmittlauch[m] has quit [*.net *.split]
ajs124 has quit [*.net *.split]
fionera has quit [*.net *.split]
mupf has quit [*.net *.split]
jonge has quit [*.net *.split]
IdleBot_a52e420f has quit [*.net *.split]
litschi has quit [*.net *.split]
shyim has quit [*.net *.split]
makefu has quit [*.net *.split]
palo has quit [*.net *.split]
das_j has quit [*.net *.split]
mbrgm has quit [*.net *.split]
h0m1 has quit [*.net *.split]
wucke13_ has quit [*.net *.split]
hax404 has quit [*.net *.split]
lassulus has quit [*.net *.split]
ehmry has quit [*.net *.split]
nervengift has quit [*.net *.split]
jonge[m] has quit [*.net *.split]
Mic92 has quit [*.net *.split]
manveru has quit [*.net *.split]
hexa- has quit [*.net *.split]
fpletz has quit [*.net *.split]
flokli has quit [*.net *.split]
betaboon has quit [*.net *.split]
CRTified has quit [*.net *.split]
clkamp_ has quit [*.net *.split]
tazjin has quit [*.net *.split]
Ox4A6F has quit [*.net *.split]
haslersn has quit [*.net *.split]
Scriptkiddi has quit [*.net *.split]
tokudan[m] has quit [*.net *.split]
marijan[m] has quit [*.net *.split]
musicmatze has quit [*.net *.split]
sphalerite has quit [*.net *.split]
ctp has quit [*.net *.split]
tv has quit [*.net *.split]
andi- has quit [Ping timeout: 240 seconds]
Scriptkiddi has joined #nixos-de
flokli has joined #nixos-de
makefu has joined #nixos-de
woffs has joined #nixos-de
h0m1 has joined #nixos-de
nervengift has joined #nixos-de
tokudan[m] has joined #nixos-de
andi- has joined #nixos-de
fendor has joined #nixos-de
fendor has quit [Ping timeout: 256 seconds]
fendor has joined #nixos-de
<musicmatze>
Na dann wäre es doch eher Zeit für n Update vom Paket, oder?
<musicmatze>
bzw n neues release falls es das noch nicht gibt
fendor has quit [Remote host closed the connection]
fendor has joined #nixos-de
<fionera>
musicmatze: Jo gibts aber noch nicht...
<fionera>
anscheinend ist endlich der bug gefixt, wodurch bei intellij das autocompletion fenster den fokus verliert
<musicmatze>
nais
<musicmatze>
also ... das der Bug gefixed ist, nicht dass es kein release gibt :-)
<musicmatze>
Na dann mal den maintainer des repos anhauen ob man nicht eine 1.4.1 oder so releasen könnte...
<musicmatze>
mit den fixes eben
<musicmatze>
oder direkt ne 1.5
<musicmatze>
fragen koschd nichts!
<fionera>
ich teste es gerade erstmal :D Aber bisher nicht wieder aufgetreten
<fionera>
bzw nicht das ich es merken würde
<musicmatze>
(Ich mag da das Verhalten in der Rust Community,.. da macht man ein Issue auf "Hey, ich hab hier das und das, könntest du ein neues release machen damit ich die fixes bekomm die ich brauch?" ... und dann wird das einfach gemacht oder zumindest entsprechend reagiert wenns grade nicht geht=
<musicmatze>
* (Ich mag da das Verhalten in der Rust Community,.. da macht man ein Issue auf "Hey, ich hab hier das und das, könntest du ein neues release machen damit ich die fixes bekomm die ich brauch?" ... und dann wird das einfach gemacht oder zumindest entsprechend reagiert wenns grade nicht geht)
<musicmatze>
In anderen communities scheint das nicht so common zu sein sich da entsprechend zu verhalten, was echt schade ist
<fionera>
ich warte immernoch auf den support für mirroring etc bei sway
<fionera>
sehr schade das dit fehlt
<palo>
hmm nixpkgs.config.packageOverrides scheint nicht mehr so wirklich zu funktionieren, ich hab das in unterschiedlichen datein gesetzt, aber nur eines der overrides scheint zu funktioniern
<palo>
musicmatze: haste dir mein rust projekt angeschaut?
<musicmatze>
da war was, gell?
<musicmatze>
Ich glaub ja, ist aber schon länger her
<palo>
ich frag nur da ich morgen oder übermorgen mit nem neuen projekt anfangen will, das ähnlich wird
<palo>
na ja nicht sooo ähnlich aber ähnlich :D
<musicmatze>
:-)
<musicmatze>
Ich werd am Samstag meine Codebases von failure auf anyhow und thiserror umbauen
<musicmatze>
bin gespannt wie gut das läuft
<musicmatze>
palo: Ich "dumpe" einfach mal was ich denke hier rein
<musicmatze>
exit(1) callen ist okay, aber IMO ist einen error returnen geiler
<musicmatze>
das geht auch von der main() aus
<musicmatze>
mit diesem Wissen kannst du im Endeffekt alle unwrap() calls in main() eliminieren indem du im entsprechenden Fall einfach einen Error generierst und returnest
<musicmatze>
also `Option::ok_or_else()` ist dein Freund
<palo>
Ok, gibts da ein best practice zu Error handling, mit Result und was es da so alles gibt?
<musicmatze>
und `?` auch.
<musicmatze>
ausserdem: Für viele `::from()` funktionen gibt es ein `try_from()` äquivalent welches im Fehlerfall einen error returned (oder `None`) ...
<musicmatze>
`#[inline(always)]` sollte man nicht nutzen. Der Rust compiler ist schlau genug das automatisch zu machen
<musicmatze>
auch `
<musicmatze>
* auch `#[inline]`
<musicmatze>
auch das normale inline braucht man eigentlich nicht
<musicmatze>
ich nutze das praktisch nie
<musicmatze>
in src/objects.rs implementierst du `pub fn default()` ... dafür gibts einen Trait den du implementieren kannst ("Default")
<musicmatze>
Anscheinend lässt du also kein clippy über die Codebase rennen, weil clippy hätte dir das gesagt ... nutze clippy!
<musicmatze>
Es macht dich zu einem besseren Menschen!
<musicmatze>
Best practice zu error handling ist aktuell die "thiserror" crate für library crates und "anyhow" für binary crates (oder ich habs verwechselt und andersrum)
<musicmatze>
IMO ist es für CLI tools am besten einfach `fn main() -> Result<()>` zu implementieren und _alle_ errors bis main() zu propagieren
<musicmatze>
Sehr geil btw dass du serde nutzt und es auch so machst wie man es machen sollte! :-)
<musicmatze>
auch sehr geil dass du destructuring nutzt (objects.rs zeile 153)
<musicmatze>
+1!
<palo>
ich kann nicht immer "Default" implementieren für i32 zum beispiel nicht, da es das schon gibt, wenn es einer meiner typen ist dann hab ich Default implementiert
<palo>
inline nutz ich nur wenn es sein muss, wenn ich will das es passiert
<palo>
clippy ist ein guter tip
<musicmatze>
Ja aber in genanntem File implementierst du es für einen eigenen Datentyp
<musicmatze>
das wird dir Clippy deswegen auch anmeckern... weils dafür ja extra einen Trait gibt
<palo>
ah ok :D danke
<palo>
jo gute tipps
<palo>
jo destructuring ~ pattern matching ist einfach super angenehm
<palo>
aber danke für die tips
<musicmatze>
wenn du den Trait implementierst bekommst du nämlich an anderen Stellen mit der stdlib auch wieder irgendwelche goodies weil irgendwelche anderen Traits halt wieder so implementiert sind dass "für alle typen die hier Default implementieren" und so geschichten...
<musicmatze>
sehr gerne!
<palo>
hmm ich bekomm dem nextcloud module einfach kein neueres nextcloud untergeschummelt
<palo>
was ist da los?
<musicmatze>
in palette.rs schreit mich `allow(dead_code)` an... frag dich ob du den Code wirklich brauchst wenn er tot ist!
<palo>
arg, ich habe name nicht überschrieben sondern pname :/
<palo>
ja den brauch ich leider
<musicmatze>
warum ist er dann tot?
<palo>
ich nehme eine farbe und generiere eine palette daraus, und davon nehm ich dann nur ein subset von farben
<palo>
oh warte kurz... ich schau lieber mal nach bevor ich aus dem gedächnis erzähle
<musicmatze>
:-)
<palo>
moment ich mach das kurz weg, da gabs fehler oder warnings
<palo>
warning: field is never used: `complement_shade_15`
<palo>
das bekomm ich dann
<palo>
wie gesagt momentan nutz ich noch nicht die ganze palette, aber irgendwan wird das so sein
<musicmatze>
jup
<musicmatze>
das struct TintAndShadePalette ist nicht `pub` ...
<palo>
aber danke für die tips werd gleich mal clippy ausprobieren
<musicmatze>
heisst vermutlich wird es nur im lokalen Modul gebraucht
<musicmatze>
aha, es wird in `bright_on_dark()` verwendet und in eine instanz von `Palette` eingebaut, aber halt ohne jemals dieses Feld zu benutzen
<musicmatze>
aka: Wird nie benutzt, ist also tot...
<musicmatze>
und wenn es nie benutzt wird kann man es raus löschen ohne Funktionalität zu verlieren
<palo>
jo, aber ich brauch das wie gesagt noch, die palette wird nach eine bestimmten schema gerstellt, und ich brauche alle farben wenn ich die ausgabe palette generiere, und mit ich meine ich selbst, denn es kommen noch mehr farb funktionen auser nur die 2 .
<palo>
hmm ich bekomm nextcloud einfach nicht auf ne neue version gehoben. das hat doch bisher immer ohne problem geklappt
<palo>
und ich mach das immer wie ich mit overlays arbeite
<musicmatze>
achso, du meinst da fehlt einfach noch code der noch nicht geschrieben ist?
<musicmatze>
Na dann ist das was anderes!
<palo>
jo, da kommen noch mehr pattern algos
<palo>
und der algo zum erstellen der super palette ist einfach nur abgekupfert.
<musicmatze>
jo, gut dann hab ich nichts gesagt
<palo>
da jetzt dran rum optimieren macht keinen sinn
<palo>
hmm ich bin ja in nem container, vielleicht muss ich im container nochmal die pkgs überschreiben.
<palo>
Aber das werd ich jetzt mal rausfinden
<palo>
musicmatze wie nutz ich denn clippy?
<palo>
ich meine wie installier ich das?
<musicmatze>
öhm
<musicmatze>
`cargo install clippy`?
<palo>
ach ok, dachte das mach ich in ner nix-shell oder so
<musicmatze>
das geht natürlich auch
<musicmatze>
`nix-shell -p clippy`
<musicmatze>
kommt drauf an wie du dein Setup gerne hast
<palo>
ne geht beides nicht
<palo>
clippy ist nicht mehr in crates.io
<palo>
ich brauch anscheinend jetzt rustup oder so
<musicmatze>
höh?
<musicmatze>
Ich hab grade hier auf meinem Testing VM auf der Arbeit `cargo install clippy` gemacht
<palo>
Oh und ja in nixos-containern muss nochmal alles override kram nochmal gemacht werden
<musicmatze>
ah, jetzt seh ichs
<musicmatze>
na dann nix-shell!
<palo>
ne nix-shell geht nicht
<palo>
der kennt kein clippy
<musicmatze>
was für n channel?
<musicmatze>
Das tut hier nämlich bei mir einwandfrei
<palo>
stable
<palo>
also 19.09
<musicmatze>
ah, okay
<musicmatze>
meine vm ist unstable
<musicmatze>
deswegen
<palo>
I see :D
<palo>
na dann warte ich einfach noch ein paar wochen :D
<musicmatze>
wenn du das mozilla-overlay benutzt tut das bestimmt
<palo>
joah, na das nutz ich noch nicht, ich dachte ich warte mal bis flakes so richtig fertig sind bevor ich solche dinge lade
<musicmatze>
ich nutz das schon bestimmt seit über einem Jahr und es hat noch nie probleme gemacht :-)
fendor has quit [Ping timeout: 240 seconds]
fendor has joined #nixos-de
<Mic92>
palo: krops funktioniert auch super um overlays zu laden.
<palo>
jo ich nutzt doch krops
<palo>
hab doch sogar die doku dafür geschrieben :D
<palo>
aber das problem war, das in containern anscheinend die pkgs overlays nicht ziehen
<Mic92>
Ich glaube ich werden irgendwann die krops Doku noch ausbauen, damit ich das bei uns in der Uni einführen kann.
<Mic92>
lassulus: apropos pre/post hooks. writeDeploy macht schon etwas mehr als einfach nur nixos-rebuild. Von daher wäre es vermutlich irgendwann doch sinnvoll echte build hooks einzuführen.
<lassulus>
stimmt, jetzt macht es auch die remote builder magie
<lassulus>
hooks könnte man auch tun
<lassulus>
aber mehr features macht alles iwann schmerzhaft
<Mic92>
lassulus: Vielleicht kann man die composability und statt einem Skript lieber die Commands zurück geben?
<Mic92>
*composability verbessern
<lassulus>
oehm, nich sicher was du meinst
<lassulus>
man könnte die einzelnen steps auch exporten, damit man sich mit writeCommand die dinge besser zusammen bauen könnte
<Mic92>
lassulus: wenn man statt skripten in jeder Funktion nur strings zurück gibt, könnte man im finalen step dann ein writeScript packen.
<Mic92>
oder writeDash
<Mic92>
Dann hat man auch weniger derivations.
<Mic92>
Irgendwann würde ich gerne auch auf mehre Hosts gleichzeitig deployen.
<Mic92>
Allerdings ist der log output dann noch ein problem.
<lassulus>
alte versionen von stockholm deploy konnten das
<lassulus>
hatten das mit parallel gemacht
<lassulus>
aber es war nicht sichtbar ob ein host gefailed war oder nich
<Mic92>
pssh geht auch alternativ.
<Mic92>
Da ist das logging dann vermutlich sauberer.
<lassulus>
kann man auf jedenfall mal testen, die frage ist halt immer wie viel dinge man konfigurierbar machen will und ab wann es sinn macht dinge neu zu bauen :D