Some stuff is better, but I overall prefer chocolatey because it is closer to classic package manager experience. Winget will still open the installer windows of some applications. But you can use both, no need to decide for one, they install into the same directories and will manage the other's applications just fine (as they're all standard Windows installers).
Either my Ansible knowledge is too limited which is entirely possible, or you can't do stuff there that's possible with Nix. Let's stay go with my example that you have something that requires changes in PAM. So you write an Ansible file installing the package (which is distribution-specific, so you're losing one advantage you had over NixOS), enable the service and add your entries to the respective PAM file (e.g. login because you want to enable user authentication against kanidm on your machine). The ordering in these files matter. Sure you have insertbefore and insertafter for lineinfile and blockinfile, but this basically requires you to know the rest of the file in advance… not a problem if your system is always the same, but you don't have the flexibility and composability that Nix offers.
I dunno man. I spent way less time configuring my machines on NixOS because it just works. But in fairness, that is after I have spent a lot of time learning it (compared to classic systems that is, not a lot compared to NixOS maintainers who write way better module than I do). Now that there is a foundation, I just run the updates. It's almost scarily stable. And the ability to group related settings together is such a bliss because you no longer wonder about "what did I do to enable X", just open the file, it's all in one place. Stuff that could be three completely different things (e.g. a service specific config file, a PAM entry and the service activation itself in effectively 5 lines. Want to do something for multiple services? Just map over their list. Etc
I happily used Arch for 15 years and after trying NixOS on a decommissioned machine for one day I switched over everything as fast as possible. And I did try out Ansible on Arch, so it's not like I didn't try management via a tool. But using a system like NixOS just solves sooo many potential issues.
It obviously comes with downsides, for example there is no quick configuration change. Changing something small requires another evaluation. Still worth it
I have never used any of these (except Uber once in 2016 maybe?) because of the exploitative model. Even though the situation here in Germany is a tad different with them. Fuck them. Regular companies are bad enough already
The issue is not only complexity, though it does play a role. You can also run into issues with pure text parsing, especially when whitespace is involved. The IP thing is a very classic example in my opinion, and while whitespace might not be an issue there (more common with filenames), the queries you find online in my opinion aren't less complex.
Normal CLI output is often meant to be consumed by humans, so the data presentation requirements are different. Then you find out that an assumption you made isn't true (e.g. due to LANG indicating a non-English language) and suddenly your matching rules don't fit.
There are just a lot of pitfalls that can make things go subtly wrong, which is why parsing general CLI output that's not intended to be parsed is often advised against. It doesn't mean that it will go wrong.
Regarding Python, I think it has a place when you do what I'd call data set processing, while what I talk about is shell plumbing. They can both use JSON, but the tools are probably not the same.
It's true that compared to the other utilities, it's rather new. First release was almost 13 years ago. awk, which I think is the closest comparison, on the other hand turns 50 in 2027... though new awk is only 40.
One might wonder if at those file sizes, working with text still makes sense. I think there's a good reason journald uses a binary format for storing all that data. And "real" databases tend to scale better than text files in a filesystem as well, even though a filesystem is a database.
Most people won't have to deal with that amount of text based data ever.
You're welcome! And actually, even this approach can yield surprising results... As in have you heard of deprecated IPv6 addresses before? Well I hadn't until I realized my interface now had one (it actually didn't anymore when I wrote the post, I used the jq command on old output, not in a pipe). Which made my DynDNS script stop working because there was now a line break in the request URL that curl rightfully failed on.
Edit: also despite what the title of the post says, in not an authoritative expert on the matter and you can use whatever works for you. I see these posts more as a basis for discussions like here than definitive guides to do something the correct way.
Maybe I should have written it differently: I think people are rather willing to install another tool than a whole new shell. The later would also require you to fundamentally change your scripts, because that's most often where you need that carefully extracted data. Otherwise manually copying and pasting would suffice.
I was thinking about writing a post about nu as well. But I wasn't sure that appeals to many, or is it should be part of something like a collection of stuff I like, together with fish as an example of a more traditional shell.
Linux also has some shells working on structured data (e.g. nu and elvish). But those don't really help you on machines that don't have those installed.
In general, I think Powershell's approach is better than the traditional one, but I really dislike the general commands. Always feels weird using it.
From a quick glance, this is pacman with a yaml file instead of a shell script and PKGINFO (the latter was introduced for the same reason you're doing it your way in the first place). The carcinization of package managers
the ability to split your system configuration into logical modules. Describe one logical thing in one file, no matter how many other factors are involved. Don't want that thing anymore? Just don't reference the module, and all changes will be reverted.
easily try out new configurations and roll back, regardless of underlying filesystem, without performance penalties.
the ability to put logic into your configuration (technically, there's no difference between what's typically referred to as configuration and a module in nix, though the latter usually has more "logic" and provides values with lower priority).
as a consequence, make modules transferable between systems. There's e.g. a Lanzaboote module that enables Secure Boot in a really smart way on NixOS, and the configuration is in my opinion easier than on any other Linux system.
the reproducibility, from which the "easy reinstallation" follows
Some stuff is better, but I overall prefer chocolatey because it is closer to classic package manager experience. Winget will still open the installer windows of some applications. But you can use both, no need to decide for one, they install into the same directories and will manage the other's applications just fine (as they're all standard Windows installers).