Proposal: Build shell completion with build script by auyer · Pull Request #72 · level1techs/siomon

auyer · 2026-07-12T03:19:40Z

Hi,
I am packaging siomon for Debian [1], and would like to propose a change that would make things easier there: generating the shell completions using the build script (build.rs, this PR).

Why it helps:
Rust packages on Debian are being built from the sources published in crates.io. Since the current xtask script is not part of the siomon package (the cargo package --list shows the included files), we are unable to just grab the files from source.

I understand if you don't want the completions to be built every time (although it is a small build).
On the other side, it makes the packaging process simpler for you too (I updated the packaging scripts too).

As always, this is optional. If you decide not to take this contribution, I will find another way, just not the simplest one.

[1] Posted on the forums: https://forum.level1techs.com/t/packaging-siomon-for-upstream-debian/251448/6

Thanks,
Rafael.

Signed-off-by: Rafael Passos <rafael@rcpassos.me>

emansom · 2026-07-12T06:38:15Z

@weriomat ping

Rust packages on Debian are being built from the sources published in crates.io

This is not a Rust library, and thus should not be packaged as such. Irrelevant.

weriomat

Halo Rafael,

this seems like a reasonable solution to your problem. As I only use nix/ build from source this is not a concern for my setup.
The overhead generating these at build time should be ignorable imo.

weriomat · 2026-07-12T09:44:23Z

 clap_complete = "4"

+[build-dependencies]
+clap = { version = "4", features = ["derive"] }


Why is the workspace dependency not used?

Oversight. Fixed. Thanks

weriomat · 2026-07-12T09:45:48Z

+include!("src/opts.rs");
+
+fn main() -> std::io::Result<()> {
+    let outdir = "./target";


Is there a reason not to respect CARGO_TARGET_DIR?

I just did not know about it! Applied it. Thanks!

After reading the docs a bit more broadly I noticed that CARGO_TARGET_DIR is used for configuring cargo itself and that OUT_DIR should be used in a build file. Like it is done in the example you linked for generate_to.
Pardon me :)

They have different behaviors. The OUT_DIR creates a different folder per build, while the former puts the file in the "root of the build folder".
I'll test both with the debian packaging tools (maybe tomorrow).

Check it out:

Using OUT_DIR:

cargo build Compiling siomon v0.2.3 (/siomon) warning: siomon@0.2.3: shell completions generated in /siomon/target/debug/build/siomon-05022c59d4204aad/out/ Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.64s

Using CARGO_TARGET_DIR:

cargo build Compiling siomon v0.2.3 (/siomon) warning: siomon@0.2.3: shell completions generated in ./target/ Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.64s

Signed-off-by: Rafael Passos <rafael@rcpassos.me>

weriomat · 2026-07-12T14:09:32Z

Just to be sure, the include! macro emits a println!("cargo:rerun-if-changed={src}"); (or something like that) such that the build file will be run again in case the src/opts.rs file changes?

weriomat · 2026-07-12T14:11:07Z

I would be in favor of bumping the version of siomon after the merge of this PR so that the nixpkgs package can be updated to the new shell completion location

auyer · 2026-07-12T14:21:48Z

Hi @emansom

Rust packages on Debian are being built from the sources published in crates.io

This is not a Rust library, and thus should not be packaged as such. Irrelevant.

To clarify the context: the Debian Rust team uses crates.io releases as the standard upstream source for both libraries and binary applications. This is a specific workflow managed via debcargo to handle dependencies systematically across the distribution.

Because Debian builds from the published crate tarball, files excluded from the crate publication (such as the xtask directory) are unavailable during the build process.

Moving the shell completion generation to build.rs addresses this limitation. It also aligns with Debian technical guidelines, which recommend generating artifacts during the build process itself rather than relying on pre-generated files or external scripts.

For reference on the process, this is documented in the Debian rust-team guide: https://rust-team.pages.debian.net/book/process-single.html

I hope this clarifies things.
Thanks

auyer · 2026-07-12T14:43:03Z

Just to be sure, the include! macro emits a println!("cargo:rerun-if-changed={src}"); (or something like that) such that the build file will be run again in case the src/opts.rs file changes?

Good point. I didn't find anything specific in the docs.
But I tested triggering a cargo build after making changes, and it always builds it even with just no-op changes.
Actually, I think it always builds the completion even when there is no change at all.

cargo build
warning: siomon@0.2.3: shell completions generated in ./target/
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.04s

Note: this warning is optional. It is used the the example for clap_complete.
https://docs.rs/clap_complete/latest/clap_complete/aot/fn.generate_to.html
I could remove it if you think it's too noisy.

weriomat · 2026-07-12T15:18:20Z

Good to know that this rebuild it every time (as expected).
IMO this warning is fine.

emansom · 2026-07-13T04:59:33Z

To clarify the context: the Debian Rust team uses crates.io releases as the standard upstream source for both libraries and binary applications. This is a specific workflow managed via debcargo to handle dependencies systematically across the distribution.

siomon should be self contained with static linking. As per the README:

"A comprehensive Linux hardware information and real-time sensor monitoring tool. Single static binary, no runtime dependencies."

Because Debian builds from the published crate tarball, files excluded from the crate publication (such as the xtask directory) are unavailable during the build process.

What about after? using the execute_after_dh_auto_build hook? Also, wait a second, why should Debian packages be reliant on third-party Rust ecosystem infrastructure (crates.io)? The source code artifact uploaded to the package builder runner should be sufficient?

Moving the shell completion generation to build.rs addresses this limitation. It also aligns with Debian technical guidelines, which recommend generating artifacts during the build process itself rather than relying on pre-generated files or external scripts.

I do not entirely agree with this rationale, as the shell completions are not essential to the function of siomon itself. However, feel free to make the Ubuntu/Debian packaging more conform to the official guidelines of the distro, if that aids in official adoption.

auyer · 2026-07-13T14:30:28Z

siomon should be self contained with static linking. As per the README:

It still is. Debian packages all dependencies separately, but for rust they are just build dependencies.
The statically built binary is shipped to users via apt.

[...] why should Debian packages be reliant on third-party Rust ecosystem infrastructure (crates.io)? The source code artifact uploaded to the package builder runner should be sufficient?

crates.io is involved in the source fetching process, not during build.
All builds on Debian happen without network dependency. But the source needs to be archived (in the Debian Archive) first. This can be done by downloading a tarball from upstream, mirroring a git repository, or in case for rust, downloading the source from crates.io. It is not the only way, but it is the simplest.

However, feel free to make the Ubuntu/Debian packaging more conform to the official guidelines of the distro, if that aids in official adoption.

It helps! That's why I opened the PR.

I'm only trying to help here.
I believe having Simon on Debian would be a good thing.

emansom · 2026-07-14T04:19:06Z

All builds on Debian happen without network dependency. But the source needs to be archived (in the Debian Archive) first. This can be done by downloading a tarball from upstream, mirroring a git repository, or in case for rust, downloading the source from crates.io. It is not the only way, but it is the simplest.

How will the release cycle look like? Does debian have some sort of bot that looks for new crates.io publications?

auyer · 2026-07-14T17:18:27Z

Does debian have some sort of bot that looks for new crates.io publications?

It does. Not only for crates.io.
As an example, the alacritty terminal is packaged from crates.io:

https://tracker.debian.org/pkg/rust-alacritty

Check the "action needed" section:
A new upstream version is available: [0.17.0](https://crates.io/api/v1/crates/alacritty/0.17.0/download)

Remove xtask completion generation

35fd346

Signed-off-by: Rafael Passos <rafael@rcpassos.me>

weriomat reviewed Jul 12, 2026

View reviewed changes

auyer added 2 commits July 12, 2026 10:59

Create a build script to generate shell completion

47a5ea8

Signed-off-by: Rafael Passos <rafael@rcpassos.me>

Update packaging to use the completion generated in normal build

69e5933

Signed-off-by: Rafael Passos <rafael@rcpassos.me>

auyer force-pushed the main branch from 995914e to 69e5933 Compare July 12, 2026 13:59

auyer changed the title ~~[Question/Proposal]: Build shell completion with build script~~ Proposal: Build shell completion with build script Jul 13, 2026

Uh oh!

Uh oh!

Conversation

auyer commented Jul 12, 2026

Uh oh!

emansom commented Jul 12, 2026

Uh oh!

weriomat left a comment

Choose a reason for hiding this comment

Uh oh!

weriomat Jul 12, 2026

Choose a reason for hiding this comment

Uh oh!

auyer Jul 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

weriomat Jul 12, 2026

Choose a reason for hiding this comment

Uh oh!

auyer Jul 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

weriomat Jul 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

auyer Jul 13, 2026

Choose a reason for hiding this comment

Uh oh!

weriomat commented Jul 12, 2026

Uh oh!

weriomat commented Jul 12, 2026

Uh oh!

auyer commented Jul 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

auyer commented Jul 12, 2026

Uh oh!

weriomat commented Jul 12, 2026

Uh oh!

emansom commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

auyer commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

emansom commented Jul 14, 2026

Uh oh!

auyer commented Jul 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

auyer Jul 12, 2026 •

edited

Loading

auyer Jul 12, 2026 •

edited

Loading

weriomat Jul 12, 2026 •

edited

Loading

auyer commented Jul 12, 2026 •

edited

Loading

emansom commented Jul 13, 2026 •

edited

Loading

auyer commented Jul 13, 2026 •

edited

Loading