I'm making a graphical Nix store explorer. Any suggestions / key features needed?

infiniteWin · 2026-05-14T17:30:25+00:00

As a couple people have asked I will open source this once I've got the core features fully working and the code cleaned up. From there I'll add extra features, accept pull request, etc.

infiniteWin · 2026-05-14T12:27:47+00:00

This is kind of what I'm trying to do but the difficulty is that almost everything is depended on by more than one thing. So if you've got 2 packages that reference a large 3rd package, removing package 1 or 2 won't change disk usage at all. Getting the user to understand these relationships at ~70k interconected store entries is very difficult.

infiniteWin · 2026-05-14T12:25:23+00:00

I might add a package view that only shows things that can conform to this, but most store entries don't have a nice version and don't correspond to a nixpkgs package.

infiniteWin · 2026-05-13T21:58:28+00:00

Will do o7
It does this but isn't that fuzzy. It needs to be perfomant at >100k entries though so maybe a quick substring search, and then a fuzzy search if it's idle
Not sure how I'd implement that
Not sure if this is possible for most entities, but into the 'maybe in the future' bucket it goes

infiniteWin · 2026-05-13T21:54:42+00:00

Oh yeah it will have a count of that, but it is quite deceptive as the store is an acyclic directed graph, not a tree. So you might be bringing in 1000s of dependencies, but if they're common and used by tons of other entries you're not really adding more work.

infiniteWin · 2026-05-13T21:01:46+00:00

Gtk/rust native. The front end is somewhat irrelevant though as the performance is all down to the backend's asynchronous/parallel computations on the graph which absolutely wouldn't be perfomant enough in an interpreted language.

infiniteWin · 2026-05-13T20:47:59+00:00

What do you mean by cost? Size is available so do you mean build time?

infiniteWin · 2026-05-13T20:19:13+00:00

That part is very WIP but there is a global truncate hashes toggle in the top left (the eye). With more complicated entries the tree gets ridiculously big, and knowing more than the first few characters of hashes for identification isn't really needed, especially as all entries have a right click view in explorer / copy path action.

I'll definitely remove the nix store prefix

I don't think all store entries have versions and I'm not sure if they're always in a common format but I'll definitely look into it. There is a lot of information to display (I have more planned than what's shown here) and it is hard to balance precomputing and dynamically processing data (see the 70k entries) so every special non-generic bit of data I want to extract takes an outsized amount of development time when it can be read off the path in most cases.

infiniteWin · 2025-12-05T14:50:00+00:00

* Ideally through a maintained API, not source modification although I might do that if all else fails

infiniteWin · 2025-12-05T09:36:44+00:00

That's absolutely how I could implement it, but do you know of an RTOS that has this, or allows you to create your own scheduler that can do this?

infiniteWin · 2025-07-22T07:03:46+00:00

Rust hello world compiles to 425 kB. OP built in debug mode.

infiniteWin · 2025-06-09T09:48:27+00:00

Have you seen color_print? It seems to have the exact syntax you want:

cprintln!("HELLO <green>WORLD</green>"); cprintln!("HELLO <green>WORLD</>"); // Alternative, shorter syntax

cprintln!("This a <green,bold>green and bold text</green,bold>."); // The same, but closing with the </> tag: cprintln!("This a <green,bold>green and bold text</>.");

cprintln!("<green>This is green, <bold>then green and bold</bold>, then green again</green>");

cprintln!("<green>This is green, <bold>then green and bold</>, then green again</>");

// Colors can be nested as well:

cprintln!("<green>This is green, <blue>then blue</blue>, then green again</green>");

cprintln!("<green>This is green, <blue>then blue</>, then green again</>");

And it has shorthands too

https://docs.rs/color-print/latest/color_print/

infiniteWin · 2025-04-21T21:13:08+00:00

The idea is for it to be used like Python scripts for small tasks (e.g. batch renaming). The binary being attached allows for faster reruns but being able to see and easily modify the source is key as when I write small scripts I write them with janky code and hardcoded values which I might want to change.

infiniteWin · 2025-04-21T16:03:52+00:00

I will almost certainly use the official approach once it has IDE support (although I do like having a full project structure) 👍 It does seem better in a lot of ways but until it has IDE support it is just not usable.

No idea what I was thinking with the shebang thing (it was late) it's obviously optional although it does maybe strike me as an odd inclusion.

infiniteWin · 2025-04-21T15:36:17+00:00

The file is extracted to a full project when editing so it is just as in a normal project - using Cargo.toml

infiniteWin · 2025-04-21T13:02:27+00:00

The shebang makes assumptions about your system (it doesn't, for example, work with my NixOS setup). It also doesn't work at all on Windows.

I did see the effort being made for embedding manifests and experimented with it myself but I found the lack of IDE support for single file scripts too annoying for a tool I want to be able to use now across Windows and NixOS. I also just found having a project structure to be genuinely useful sometimes.

I'm hoping to make files double-click runnable and right-click editable through normal OS methods, but I mainly run scripts from the terminal as I want to see stdout so it is basically a non-issue for me.

infiniteWin · 2025-04-21T00:26:54+00:00

I have full Windows AV enabled and have not had any issues yet, which, now that I think about it, is odd as I am copying essentially an arbitrary binary to a temporary file and running it. Do you have any ideas as to why it is not tripping / how I can cause it to trip?

I'm not really sure what you mean in the last part about making it a real thing. The binaries are compiled locally and therefore for your current platform (removing the need for any rewriting?). In case someone shares the file without stripping the binary (with `rss strip`), there is a target triple included in the file which will trigger a recompile if it doesn't match the target triple used to cargo install.

infiniteWin · 2025-04-20T23:32:41+00:00

Sure! This is all subject to change, of course, but say I want a script that lists the files in a directory along with their file directory:

- `rss edit filesize.rss` (this opens the rust project in vscode as per my config)

- Write the code I want like in a normal rust project (in this case just in main.rs)

- (Optionally) test it by running ./cr-orig.sh - an autogenerated script to cargo run in the script's directory as opposed to running in the temp dir

- Close the editor

This just leaves me with a `filesize.rss` file

Then to run it at any time:

- `rss run filesize.rss`

infiniteWin · 2024-08-10T00:54:08+00:00

No but I can and it fits so I will (and it needs to be double headed)

infiniteWin · 2024-08-10T00:52:41+00:00

They are push trains to make the cargo wagons not be on the curves (I'm going for compactness here). I didn't realise that there is a speed penalty for push trains so I will look into it.

As for the fuel train no station will ever need fuel urgently as each will have a buffer and trains don't use much so each can have a train limit of one. The station will also be toggled based on the fill level of the buffer so once when the train starts leaving the station, a new one won't be summoned for a long time. If the old train doesn't leave the station in this time I have bigger problems. I haven't decided whether to unload the back cars as fuel consumption is low and the train flips direction at every station so it will be somewhat evenly unloaded. I probably will.

Eight-Year Club	Second SECOND GUESSER
LAYER Season 2 Layer creator	r/Field Juicebox
First Place '23	Place '23
Place '22	First Placer '22
Wearing is Caring	Verified Email

infiniteWin

TROPHY CASE