WIP: feat: add Rust build backend #334

koru commented 2026年07月04日 21:47:01 +02:00

I think it's better to use Rust instead of Python + Bash.

Why?

1. I don't like uv and Python at distro packaging.
2. I'm learning Rust and it's awesome practice for me.
3. Less files means easy to maintain. Still isn't KISS/suckless/POSIX, but better than a lot of bash scripts.
4. Prepare (???) for CLI/TUI to install on unsupported platforms (ex. Windows).
5. Reproducible builds.
6. Less remote files/assets (uv, tools, python, etc...)

TODO:

1. Configs can be built using Rust backend.
2. Shared lib to Dove. See: celenity/Dove#75.
3. Reproducible builds. Thanks to @degausser! See: 1, 2.
4. Do not use system tools and libs.
5. Update Nix build.
6. Update CI/CD scripts (if any).
7. Add more tests for cargo test.
8. Test build at Windows and macOS.

How to:

1. Checkout branch.
2. cargo run.
3. Files at /build/ folder.

Closes: #271, #308, #314, #315.

I think it's better to use Rust instead of Python + Bash. **Why?** 1. I don't like uv and Python at distro packaging. 2. I'm learning Rust and it's awesome practice for me. 3. Less files means easy to maintain. Still isn't KISS/suckless/POSIX, but better than a lot of bash scripts. 4. Prepare (???) for CLI/TUI to install on unsupported platforms (ex. Windows). 5. Reproducible builds. 6. Less remote files/assets (uv, tools, python, etc...) **TODO:** 1. [x] Configs can be built using Rust backend. 2. [ ] Shared lib to Dove. See: https://codeberg.org/celenity/Dove/issues/75. 3. [x] Reproducible builds. Thanks to @degausser! See: [1](https://codeberg.org/celenity/Phoenix/issues/314#issuecomment-17258324), [2](https://codeberg.org/celenity/Phoenix/issues/314#issuecomment-17259887). 4. [ ] Do not use system tools and libs. 5. [ ] Update Nix build. 6. [ ] Update CI/CD scripts (if any). 7. [ ] Add more tests for `cargo test`. 8. [ ] Test build at Windows and macOS. **How to:** 1. Checkout branch. 2. `cargo run`. 3. Files at `/build/` folder. Closes: #271, #308, #314, #315.

degausser commented 2026年07月05日 03:27:12 +02:00

since i was tagged,

I think it's better to use Rust instead of Python + Bash.

"От волка бежал, да на медведя напал"

nothing against the language (more of a golang guy myself), but i'm not a fan of riir for the sake of it. since it's a rewrite, there has to be a better way to do some operations, like this for example (regex?), despite how let's say verbose the original python scripts are... it also still depends on at least jq for json parsing, coreutils, archivers... not really a cross-platform freestanding binary.

i think the best you can hope for is rust as an alternative backend (which would bloat the repo a bit, but whatever), but i wouldn't count on it.

personally, i don't think there should be an elaborate build process to speak of at all, since e.g. the cfg is basically done by cat-ing -core and -unified together and a few string replaces; policy differences on !mail desktop boil down to different path to shipped vanity bookmarks (??? why not just check in 3 separate policy files for [1.] all desktop, [2.] mail and [3.] android and be done with it...) i think celenity went a bit overboard with the "infra" aspect in a few places (like "building" the badblock lists txt->txt...), but if build portability is the goal, downporting the scripts to posix+make and possibly ditching python/jq would allow for building in busybox, even on windows (not needing wsl), which is likely as portable (*nix) as it gets.

all that being said,

I'm learning Rust and it's awesome practice for me.

i sincerely wish you good luck and i hope you persevere, may all your checks be borrowed (or borrows checked).

since i was tagged, >I think it's better to use Rust instead of Python + Bash. "От волка бежал, да на медведя напал" nothing against the language (more of a golang guy myself), but i'm not a fan of [riir](https://github.com/ansuz/RIIR) for the sake of it. since it's a rewrite, there has to be a better way to do some operations, like [this](https://codeberg.org/celenity/Phoenix/src/commit/cc64f04679c143cb8e6de5a7664d53de3b61106e/src/builder.rs#L20-L57) for example (regex?), despite how let's say _verbose_ the original python scripts [are](https://codeberg.org/celenity/Phoenix/src/branch/dev/scripts/convert-cfg-to-js.py)... it also still depends on at least jq for json parsing, coreutils, archivers... not really a cross-platform freestanding binary. i think the best you can hope for is rust as an _alternative_ backend (which would bloat the repo a bit, but whatever), but i wouldn't count on it. personally, i don't think there should be an elaborate build process to speak of at all, since e.g. the cfg is basically done by cat-ing -core and -unified together and a few string replaces; policy differences on !mail desktop boil down to _different path to shipped vanity bookmarks_ (??? why not just check in 3 separate policy files for [1.] all desktop, [2.] mail and [3.] android and be done with it...) i think celenity went a bit overboard with the "infra" aspect in a few places (like "building" the badblock lists txt->txt...), but if build portability is the goal, downporting the scripts to posix+make and possibly ditching python/jq would allow for building in busybox, even on [windows](https://frippery.org/busybox/) (not needing wsl), which is likely as portable (*nix) as it gets. all that being said, >I'm learning Rust and it's awesome practice for me. i sincerely wish you good luck and i hope you persevere, _may all your checks be borrowed (or borrows checked)._

degausser commented 2026年07月05日 06:00:21 +02:00

@celenity

not sure if this would be also covered by the comment ( :) ), but you could remove convert-cfg-to-js.py completely by replacing this line with the following oneliner (any posix awk is enough, seems gawk is already used elsewhere; could be also a herestring instead of cat if further bashisms are fine):

cat "${phoenix_output_dir}/phoenix.cfg" | awk '!/\[FN\]/&&/^ *(defaultP|lockP|p)ref\(/{if(/^ *lock/){sub(/\)/,", locked)")};sub(/.*ref\(/,"pref(")}1' >"${PHOENIX_TEMP}/phoenix-static-temp-${phoenix_js_platform}.js"

this oneliner would then replace convert-js-to-cfg.py:

cat "1ドル" | awk '/pref\(/{if(/, locked/){sub(/, locked/,"");sub(/pref\(/,"lockPref(")}else{if(/, sticky/){sub(/, sticky/,"")}else{sub(/pref\(/,"defaultPref(")}}}1' >"2ドル"

@celenity https://codeberg.org/celenity/Phoenix/src/commit/2ad5e86d48e9df6c05fcd1ab8217227103dcb268/scripts/convert-cfg-to-js.py#L9 not sure if this would be also covered by the comment ( :) ), but you could remove `convert-cfg-to-js.py` completely by replacing [this line](https://codeberg.org/celenity/Phoenix/src/commit/2ad5e86d48e9df6c05fcd1ab8217227103dcb268/scripts/fly.sh#L654) with the following oneliner (any posix awk is enough, seems gawk is already used elsewhere; could be also a herestring instead of cat if further bashisms are fine): ```sh cat "${phoenix_output_dir}/phoenix.cfg" | awk '!/\[FN\]/&&/^ *(defaultP|lockP|p)ref\(/{if(/^ *lock/){sub(/\)/,", locked)")};sub(/.*ref\(/,"pref(")}1' >"${PHOENIX_TEMP}/phoenix-static-temp-${phoenix_js_platform}.js" ``` this oneliner would then replace `convert-js-to-cfg.py`: ```sh cat "1ドル" | awk '/pref\(/{if(/, locked/){sub(/, locked/,"");sub(/pref\(/,"lockPref(")}else{if(/, sticky/){sub(/, sticky/,"")}else{sub(/pref\(/,"defaultPref(")}}}1' >"2ドル" ```

koru commented 2026年07月05日 08:31:03 +02:00

As always, thanks for the detailed answer!

since i was tagged,

I think it's better to use Rust instead of Python + Bash.

"От волка бежал, да на медведя напал"

nothing against the language (more of a golang guy myself), but i'm not a fan of riir for the sake of it. since it's a rewrite, there has to be a better way to do some operations, like this for example (regex?), despite how let's say verbose the original python scripts are... it also still depends on at least jq for json parsing, coreutils, archivers... not really a cross-platform freestanding binary.

Yes, actually, it wasn’t really about the "propaganda" or "agenda" behind rewriting it in Rust, it just so happened that I started learning it because I was tired of working with C++ in Unreal Engine.

personally, i don't think there should be an elaborate build process to speak of at all, since e.g. the cfg is basically done by cat-ing -core and -unified together and a few string replaces; policy differences on !mail desktop boil down to different path to shipped vanity bookmarks (??? why not just check in 3 separate policy files for [1.] all desktop, [2.] mail and [3.] android and be done with it...) i think celenity went a bit overboard with the "infra" aspect in a few places (like "building" the badblock lists txt->txt...), but if build portability is the goal, downporting the scripts to posix+make and possibly ditching python/jq would allow for building in busybox, even on windows (not needing wsl), which is likely as portable (*nix) as it gets.

System applications used to work with files, I think we really need to move toward cross-platform application that can work with other @celenity projects without having to copy the logic or use of system-specific libs/apps.

In any case, I’m always open to discussion.

I'm learning Rust and it's awesome practice for me.

i sincerely wish you good luck and i hope you persevere, may all your checks be borrowed (or borrows checked).

Thank you!

As always, thanks for the detailed answer! > since i was tagged, > > > I think it's better to use Rust instead of Python + Bash. > > "От волка бежал, да на медведя напал" > > nothing against the language (more of a golang guy myself), but i'm not a fan of [riir](https://github.com/ansuz/RIIR) for the sake of it. since it's a rewrite, there has to be a better way to do some operations, like [this](https://codeberg.org/celenity/Phoenix/src/commit/cc64f04679c143cb8e6de5a7664d53de3b61106e/src/builder.rs#L20-L57) for example (regex?), despite how let's say _verbose_ the original python scripts [are](https://codeberg.org/celenity/Phoenix/src/branch/dev/scripts/convert-cfg-to-js.py)... it also still depends on at least jq for json parsing, coreutils, archivers... not really a cross-platform freestanding binary. Yes, actually, it wasn’t really about the "propaganda" or "agenda" behind rewriting it in Rust, it just so happened that I started learning it because I was tired of working with C++ in Unreal Engine. > personally, i don't think there should be an elaborate build process to speak of at all, since e.g. the cfg is basically done by cat-ing -core and -unified together and a few string replaces; policy differences on !mail desktop boil down to _different path to shipped vanity bookmarks_ (??? why not just check in 3 separate policy files for [1.] all desktop, [2.] mail and [3.] android and be done with it...) i think celenity went a bit overboard with the "infra" aspect in a few places (like "building" the badblock lists txt->txt...), but if build portability is the goal, downporting the scripts to posix+make and possibly ditching python/jq would allow for building in busybox, even on [windows](https://frippery.org/busybox/) (not needing wsl), which is likely as portable (*nix) as it gets. System applications used to work with files, I think we really need to move toward cross-platform application that can work with other @celenity projects without having to copy the logic or use of system-specific libs/apps. In any case, I’m always open to discussion. > > I'm learning Rust and it's awesome practice for me. > > i sincerely wish you good luck and i hope you persevere, _may all your checks be borrowed (or borrows checked)._ Thank you!

This pull request has changes conflicting with the target branch.