Since I like to use bemenu I just wrote the derivation myself, it’s super short and simple especially borrowing from the build.sh script in wofi-emoji repository. You can get the emoji data like so:

emoji-data = pkgs.runCommand "emoji-data" {
        buildInputs = [ pkgs.cacert pkgs.curl pkgs.jq ];
        outputHashAlgo = "sha256";
        outputHash = "sha256-znAwFu0vq2B7lQ8uvG0xKv9j3jYr6P0CZpjoKMNPhZw=";
      } ''
        curl 'https://raw.githubusercontent.com/muan/emojilib/v3.0.6/dist/emoji-en-US.json' \
            | jq --raw-output '. | to_entries | .[] | .key + " " + (.value | join(" ") | sub("_"; " "; "g"))' \
            > $out
      '';

And then write a small wrapper script of your liking. I’m using wtype and bemenu, but you could just as easily use wl-clipboard and rofi for instance. This is to me one of the huge benifits of nix, how you can slam these small scripts together and not worry about missing dependencies when taking the configuration to other systems.

While I agree that first party systems suck, as someone with neither an iOS or Android device I personally prefer something work rather than a screen that says “connect iOS/Android”.

Yeah, sort of. I probably didn’t explain super well, and also probably don’t fully understand the problem so here are some code snippets that might make things more concrete and you can tell me where my asumptions of your codebase are wrong

So first off we have what I assume you were suggesting with multiple options for the individual db props. I commented where things are painful and bug prone:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2ecb08dd5d54378c693a7014599e8645

If Option is indeed the aproach you want to take we can solve a lot of these problems by moving all the fields that go optional together into a separate struct:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9eb2f896e171507acb64283d5b530673

We get even more type safety and clarity by making them separate types (and have ArmyWithDbProps wrap Army):

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c2e33aa1c09538ffdbe0cd440bbff3e1

Or we could use Into if it’s not appropriate for process_army_from_db to turn an ArmyWithDbProps into an Army:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f82043935625572cb08c240f23944f0e

Also this last example is using clone when if this is in-fact the direction you want to go we could be using pointers to avoid unnecessary clones. Let me know if this is the case and I can write a version with pointers and lifetimes.

I’m sure we’ve missed something here specific to your software (obviously the above links are all trivial examples), but I just wanted to help clarify my original point with some concrete code. If you can share some of your code we might be able to give you more specific advice.

Rust has a strong emphasis on strongly typing constraints. So if a collection of fields are always some/none together having them listed as separate options in the struct means there is some assumptions you are making that the type system isn’t aware of which can lead to pain and bugs in the future.

I agree that separate types with Into sounds like a nice solution to me, it would be good to see the error the compiler is giving you (or if you can a minimal reproducible repo). If you absolutely can’t make it work, a single Option<Inner> at least would be more correct as all the fields on the inner struct would be optional together.