The entire nixfmt project recently has been a big disappointment for me. nixpkgs-fmt would have been a good starting point, having a balance between enforcing rules and allowing some freedom. While nixfmt initially started with outdated ideas like 80 line length and ill fitted tries to enforce that. Adding new lines before long strings like URLs, sometimes nudging people to split them with a + which makes greping for them unnecessarily hard. They didged that which is good.
Then that people are sprinting ahead and reformatting single packages in otherwise straight forward PRs is not improving the situation in any way and is just creating lots of noise. Most often those commits are also not added to the ignore refs file and clutter git blame.
Then also issues like mentioned above might still get fixed in the future which then could result in yet another round of formatting changes because of the now strictness of nixfmt.
But at the same time adding rules, especially around lib.optional*, which often results in ugly formatted code that has strange line breaks and the general placement of the entire structure feels wrong.
Also that just appending something to a list like structure can result in the reformat of the entire thing which can make a simple one line change be blown up in the diff to many more lines.
At least an issue for that exists after arguing with them for a bit.
Does it matter in the end? Probably not that much but it will create a lot of noise on the way and will make my live of cherry-picking specific changes from master to the stable branch probably a lot more miserable and with lots more merge conflicts to solve.
Usually people are very focused to reduce churn but looking at the formatting topic some people seem to completely thrown that mindset overboard.
Den Rückbau des Zebrastreifens "begründet die Stadt Meißen mit einer Entscheidung der Unfallkommission, die dort eine Häufung von Kollisionen festgestellt hatte. Ausgelöst wurden diese vielfach durch Radfahrer, die stadteinwärts fahrend den Überweg rechtswidrig benutzen."
Warum nutzen so viele pöhse Radfahrende den Zebrastreifen wohl rechtswidrig? 🤔
anyone have a good resource for converting a binary to a #nixos service? I think i got pretty far with @readeckhttps://readeck.org/en/docs/deploy but i have no clue how to handle the /etc/ files it claims it needs and keep getting vague 203 errors.
@clerie@leona Doing pretty much the same. I have basically a 15 line shell script which does eval, copies the drv over and then builds it local or remote abd does the activation.
Hätte jetzt nicht erwartet, dass die Frage "was ist der Default-Browser" unter Linux jetzt erst mal mehrere tausend Zeilen Shellscripte offenbart, die .desktop-Files auswerten, aber andererseits bin ich auch nicht unbedingt besonders überrascht.
@leah Es gibt jetzt endlich einen Übersichtstab für Threads, aber angeblich hab ich noch keine Threads und konnte bis jetzt nur die Fehlermeldung testen.
@yisraeldov@chrism NixOS is not deeply embedded into GitHub. Many CI checks are just executing shell code in the end which can be early run locally and be adopted and everything specific to GitHub would need to find a replacement, like the labeler.
The main problem is scalability. Running your own infrastructure on that level of size, complexity and availability is a major undertaking and eg. Gitea couldn't even handle the amount of forks.
You know why I like @forgejo so much? I just did a "fly-by" patch on the documentation because I was annoyed with how complicated that one page was written. So I forked the repo, cleaned up that page and submitted a Pull Request. And guess what? No discussions, no back and forth, it just got merged! Now THAT is how you attract new contributors to your Open Source project. Thank you! My first contribution!