Gavin Masterson

@hayesstw @GrahamDowns There is this one: "lolsob"

Without providing solid evidence of poor performance, the timing of the request for removal is highly suspect given the role of Dion George in COP30.

Dion George axed, despite ‘doing my job without fear, favour or prejudice’ https://share.google/yal7cD55Y92GXhQkY

I love #nix because it allows me to reproduce software states so reliably that I now take it for granted.

I dislike #nix because I cannot encourage teams I work with to use it. The main limitation is the lack of a universal workflow that I can advocate for - particularly for non-nix developers.

Personally, I use non-overlapping nix workflows for different projects. And that is just with 'classic' nix. Flakes, lix, tvix, snix, flox et al just add to the overwhelm for new people.

My last foray into containerising #nix development shells was a partial success. It worked for simple shells, but not the more complicated version of shells that are required for bigger projects.

Are there any premium-quality examples of the process in repos or blogs that I have not found yet?

Thanks in advance. (I will keep searching/reading, but like many things with #nix, it seems when you know a workflow, you know it - but you can't easily reproduce that path for others)

@jimbob@aus.social I don't have time to test the use of nix for this, but if it is archived in nix, you could run the {insol} code in a nix-shell, and get around the CRAN issue.

@ryanmcshane@fosstodon.org @wardrup@babka.social @rstats@a.gup.pe @hadleywickham@fosstodon.org The TL;DR of all conversations I have digested is: The subtle differences in the behaviour of <- and = mean that reserving = for argument assignment, and <- for variable assignment will prevent most annoying consequences.

@stefan@social.lol My barrier to the entire #nix project is the scattered, poor/outdated/conflicting documentation.