I was a little sad that this had nothing to do with nix the distribution/package manager/language. :)
same here… It is probably good warning the author that choosing a name starting with nix, while there is a NixOs distribution, and a Nix language, with tools like nix repl, nix-build, nix-shell, nix-store, nix-env, nix-doc… that such a name may create confusion.
Just my two cents.
On the other side, while the *nix acronym was already used in the 2000s, instead of Nix/NixOs, they could have chosen Nyx (the goddess of the Night).
That makes three cents.
Better yet, there literally is a nix-info command, generally used for people to include information alongside issue reports.
$ nix-info -m
- system: `"x86_64-darwin"`
- host os: `Darwin 19.5.0, macOS 10.15.5`
- multi-user?: `no`
- sandbox: `yes`
- version: `nix-env (Nix) 2.3.4`
- channels(abathur): `"darwin, nixpkgs-20.09pre237891.f9eba87bf03"`
- nixpkgs: `/Users/abathur/.nix-defexpr/channels/nixpkgs`
Exactly! I came across this crate when I was looking for Nix store support functions, and sadly it was not it. Also, it didn’t support FreeBSD, if I recall correctly, so the crate might be misnamed.
Not misnamed, just not implemented yet. I feel like for the most part I have the Linux side covered, I still need to implement the BSD side of things.
I’ve been very busy lately juggling around multiple projects and in real life things, I just haven’t found the time to implement it yet.
This is my first lib crate in Rust. I feel like enough work has been put into it to warrant it’s own post.
Please let me know what you all think, I would really love to make this better!
It’s a crate which provides functions that output various system info in *nix such as cpu, distro, environment (de/wm), package counts, etc.
It was initially a part of my rsfetch (neofetch alternative in Rust) rewrite, but I felt like the info gathering functions would go great in a lib crate. And I’m quite happy with the results so far. I feel like this is going quite well for my first lib crate.
Might be worth noting that this won’t work at all on any non-Linux systems though (many don’t have /proc, and on some UNIX systems, files in /proc are not plaintext, many don’t have /sys). Would you be interested in advice on how to structure it to be more multi-platform friendly? Or do you want to keep it Linux-specific?
I plan on supporting BSDs as well for sure! Otherwise nix (as in *nix) would be a misleading title. I know mostly what I need to do to get them supported, I just haven’t gotten around to implementing it yet. I’m juggling around multiple projects right now, along with various in real life things.
If there are any other *nix operating systems that people use and would like support for, I’d be more than happy to add it.
And yeah, advice would be great! :)
Nice! I’ve had to write a lot of these functions for a project I’m working on so it’ll be convenient to use this in the future.
Just a note: I got a panic when I tried to get the window manager (I use sway on NixOS). Returning an io::Result for nixinfo::environment() and an Option for nixinfo::env() could work a lot better, especially for headless or strange systems.
Returning a Result<String> was actually the next thing I had listed for nixinfo. :)
And I’ll look into Option. I’ve never worked with Options before and this crate was the first time I really started working with Result.
Thanks for the note.
Edit: Result<String> and Option<String> have been implemented for environment() and env() respectively.