A nice blogpost from a #Guix user who, alas, didn't stick with it (it sounds to me like a lot of their problems were probably due to proprietary nvidia drivers adding instability but it's hard to know) but says a lot of interesting and useful things, including about how nice and empowering being a contributor feels https://nemin.hu/guix-one-month-later.html
Also, yet another Haunt site :)
@cwebber Oh, it's very nice to see my post shared here. Thank you!
I love you folks' work at Spritely. Hoot has been on my radar for quite a while and Goblins seems very cool too, even if I couldn't entirely wrap my head around it just yet.
>Haunt
I really enjoy using it. SXML makes tinkering on my blog's layout so simple. I used to use Eleventy and Jekyll, but I'm having far more fun with Haunt. Less dependencies, less complexity, yet same expressive power, what a bargain.
@cwebber Keeping in mind that Guix is a time traveler database would bring even more insights about the commit logs and atomic style of change
The idea is - in each point of time travel on time-machine you hope to have a working health graph to work with
@cwebber Amazingly insightful post!
There’s a lot to learn from it as a Guix developer; we should really have a UX/DX team that could turn high-quality reports like this into concrete milestones.
@cwebber
2.1.1: My 5 year old issue about Snapper just got closed today. So 8 months is quite qaint. 
2.2: Absolutely my biggest technical issue with Guix development workflow. I remember hoping to experience the famed debuggability of Lisp when I got started with it, but I never really got to a point where it was any more pleasant than all the "boring" languages I use. In many aspects it was worse. And Geiser is not very reliable.
"There is no programmatic way of telling if the user was just silly or if there really is a variable somewhere in some yet unused module."
There absolutely is, Roslyn can do it for C# with no issue. You "just" need to index all exports in all available modules.
2.2.3: YYyyup. I've brought this up a *lot*, I even built tooling to automate it. You can actually catch dependency cycles by analyzing the graph exports, but it should really be built-in.
Module level cycles are trickier.
2.3: Automated refactoring would be a really cool showcase of Lisp's power.
2.4: Changelog is a huge timewaste imho. Contributor time is already extremely scarce, I don't get why the project hasn't dropped this.
And again, it would be a great showcase of Lisp's powers to just generate this info automatically, or better yet, make it into a queryable database.
3.2: Yes, please, there should be a wiki. Well, there's the cookbook, but having to jump through the email and git hoops to contribute to that is Not Fun.
3.3: This is a tricky one, but I do think there should be some workarounds for accidentally trying to build things like Thunderbird of Firefox. Like, if a derivation already failed on the substitute server, just give up. It also shouldn't be hard to give an order of magnitude estimate for the resources a derivation would take. Collect some stats by package name on the build servers, guix consults them before upgrading your SBC or netbook.
Or maybe have the option to outright refuse to build anything that doesn't have the local build tag.
But OP could have used --do-not-upgrade, something I sadly became intimately familiar with during my time with Guix.
3.4: Nonguix should not be necessary, but Andy has already written about this better than I could.
4: I'm glad to see that a lot of these are being addressed. 
I hope I'll have the time&motivation someday again to contribute to it again. The move to Codeberg is already very promising.
@sharlatan @cwebber Does it show the cycle itself? The Python utility I made printed a nice a->b->c->a path.
@sharlatan @cwebber Nice, good to know there's been progress on this front.
@csepp @cwebber it was there for at least 3y ;-)
https://guix.gnu.org/manual/1.5.0/en/html_node/Cyclic-Module-Dependencies.html
Probably documentation needs to be improved
@cwebber My pie-in-the-sky vision for Guix is that Guile gets a complete Roslyn-style overhaul and becomes more like a program database. There are a lot of package import/upgrade/repair tasks that could be done semi-automatically that way.
Imagine if we could let loose some machine learning algorithms that could parse package build logs and automatically add a missing dependency.
Couple that with a time dimension and you could even use historical data to have it learn patterns.
