virtme-ng-init: add some useful info when PID>1 #256

jimc · 2025-03-19T04:27:34Z

report vng-init version info, as written to src/version.rs, by ../setup.py, using version.py's notion of VERSION.

this yields:

[jimc@gandalf virtme-ng]$ ./virtme/guest/bin/virtme-ng-init virtme-ng-init: must be run as PID 1
virtme-ng-init: Build Information:
virtme-ng-init: Package Name: virtme-ng-init
virtme-ng-init: Package Version: 1.33+33.g5893a4b.dirty
virtme-ng-init: Manifest Directory: /home/jimc/projects/virtme-ng/virtme_ng_init

or:
_ _
__ ()_ | | _ __ ___ ___ _ __ __ _
\ \ / / | | | _ _ \ / _ ____| _ \ / _ |
\ V /| | | | || | | | | | /| | | | (| |
_/ ||| _|| || |_|_| || ||__ |
|___/
kernel version: 6.14.0-rc7-dd-00059-gb4d7289f3f54 x86_64
virtme-ng-init version: 1.33+34.g723e552.dirty
(CTRL+d to exit)

So far, its only useful for blaming, but theres room for more details, if/when any useful ones become apparent.

jimc · 2025-03-20T22:52:33Z

ok. this is probably no go.
setyp.py writes version.rs into the subdir.
so its a build artifact.
but then its not in the repo for clean builds everwhere.

matttbe · 2025-03-28T16:20:19Z

setup.py

+# Generate Rust version file
+version_rs_path = pathlib.Path("virtme_ng_init/src/version.rs")
+version_rs_path.parent.mkdir(parents=True, exist_ok=True)
+version_rs_path.write_text(f'pub const VERSION: &str = "{VERSION}";\n')


will it write this info in the source code, modifying the tracked file?

That's a good idea to pass the version, but can we not pass the info differently? e.g. passing a var when compiling the program?

Yes. setup.py writes the whole file.

I fiddled with trying to get env at compile-time, but that env isnt a hash, so I cant just inspect it for useful datums.
Some AI showed me a long list of things, not many looked useful. I settled on 3 as a POC.

FWIW, the placeholder version serves as a sentinel,
making clear that something is off with the build process.
But it does muddle the meaning of "clean source"

If that's not easily possible, an env var could be passed to the VM.

following up on this, I asked the LLM:

Ive done the placeholder version like you suggested, but it opens another problem: the build process now alters the checked-out code, so it no longer would match a checksum baseline. Some CI might barf on that.

Heres its (slightly solicitous) response: It sounds plausible to me, but this is like week 2 of my rust world. Anyone foresee any troubles ??

You've hit upon a very important point! Creating a placeholder version.rs and then having the build process overwrite it does indeed introduce the problem of altering checked-out code, which can cause checksum mismatches and CI failures.

Let's address this issue with a solution that avoids modifying checked-out code:

The Solution: Generate version.rs in the target Directory

Instead of generating version.rs in the src directory, we can generate it in the target directory, which is already ignored by Git and intended for build artifacts.

Here's how to implement this solution:

Modify setup.py:

Change the version_rs_path to point to the target directory:

Python

version_rs_path = pathlib.Path("virtme_ng_init/target/version.rs")
Ensure the directory exists:

Python

version_rs_path.parent.mkdir(parents=True, exist_ok=True)
Generate the version.rs file in the target directory:

Python

version_rs_path.write_text(f'pub const VERSION: &str = "{VERSION}";\n')
Modify virtme_ng_init/src/main.rs:

Change the mod version; declaration to point to the target directory:

Rust

mod version;
use crate::version::VERSION;
Update .gitignore:

Ensure that the virtme_ng_init/target/version.rs file is ignored by Git.
The virtme_ng_init/target directory is already ignored, so there should be nothing to do.
Explanation

By generating version.rs in the target directory, we avoid modifying checked-out code.
The target directory is intended for build artifacts and is already ignored by Git, so it won't affect checksums or CI.
We change the mod declaration to mod version; and then use crate::version::VERSION to tell rust to look for the module in the same crate, which is the default behavior.
Benefits

No Modification of Checked-Out Code: This resolves the checksum and CI issues.
Clean Build: The build process generates files in the appropriate location.
Compatibility: This approach should be compatible with most CI systems.
By generating version.rs in the target directory, you can resolve the pre-commit rejection and avoid modifying checked-out code.

I don't know Rust well, (maybe @arighi can help here? :) ) but I think the idea is to add a build.rs file in virtme_ng_init/ that will execute python3 virtme_ng/version.py and set a build env var:

// build.rs use std::process::Command; fn main() { // note: add error checking yourself. let output = Command::new("python3").args(&["virtme_ng/version.py"]).output().unwrap(); let version = String::from_utf8(output.stdout).unwrap(); println!("cargo:rustc-env=VNG_VERSION={}", version); }

Then in main.rs, you can use env!("VNG_VERSION")

Source: https://stackoverflow.com/a/44407625

virtme_ng_init/src/main.rs

report virtme-ng-init version info, as written to target/version.rs, by ../setup.py, using version.py's notion of VERSION. this yields: [jimc@gandalf virtme-ng]$ ./virtme/guest/bin/virtme-ng-init virtme-ng-init: must be run as PID 1 virtme-ng-init: Build Information: virtme-ng-init: Package Name: virtme-ng-init virtme-ng-init: Package Version: 1.33+33.g5893a4b.dirty virtme-ng-init: Manifest Directory: /home/jimc/projects/virtme-ng/virtme_ng_init or: _ _ __ _(_)_ __| |_ _ __ ___ ___ _ __ __ _ \ \ / / | __| __| _ _ \ / _ \_____| _ \ / _ | \ V /| | | | |_| | | | | | __/_____| | | | (_| | \_/ |_|_| \__|_| |_| |_|\___| |_| |_|\__ | |___/ version: 1.33+34.g723e552.dirty kernel: 6.14.0-rc7-dd-00059-gb4d7289f3f54 x86_64 (CTRL+d to exit) So far, the info is mostly useful for blaming, but theres room for more details, if/when any other useful ones become apparent. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> --- v2 - version in target, to avoid repo/checksum/build/CI conflicts

jimc · 2025-04-07T15:13:11Z

So it appears that setup.py is not run 1st as part of CI

it writes the target/version.rs file, which must be there for the compile to succeed.

Can someone conjure a fix ?

matttbe · 2025-04-07T16:42:23Z

setup.py

+# Generate Rust version file
+version_rs_path = pathlib.Path("virtme_ng_init/src/version.rs")
+version_rs_path.parent.mkdir(parents=True, exist_ok=True)
+version_rs_path.write_text(f'pub const VERSION: &str = "{VERSION}";\n')


I don't know Rust well, (maybe @arighi can help here? :) ) but I think the idea is to add a build.rs file in virtme_ng_init/ that will execute python3 virtme_ng/version.py and set a build env var:

// build.rs use std::process::Command; fn main() { // note: add error checking yourself. let output = Command::new("python3").args(&["virtme_ng/version.py"]).output().unwrap(); let version = String::from_utf8(output.stdout).unwrap(); println!("cargo:rustc-env=VNG_VERSION={}", version); }

Then in main.rs, you can use env!("VNG_VERSION")

Source: https://stackoverflow.com/a/44407625

jimc · 2025-04-07T18:45:17Z

can we depend upon package variables ?

use std::env;
use std::fs;
use std::path::Path;

fn main() {
    // This is a simplified example - you'd need a robust way
    // to get the VERSION from your Python setup.py

    // For demonstration, let's hardcode a version or get it from an env var
    let version = env::var("CARGO_PKG_VERSION").unwrap_or("0.1.0");
    let out_dir = env::var("OUT_DIR").unwrap();
    let dest_path = Path::new(&out_dir).join("version.rs");

    fs::write(
        &dest_path,
        format!("pub const VERSION: &str = \"{}\";\n", version),
    )
    .unwrap();

    println!("cargo:rustc-env=BUILD_VERSION={}", version);
    println!("cargo:rustc-cfg=build_version=\"{}\"", version);
}

jimc · 2025-04-07T18:55:53Z

On Mon, Apr 7, 2025 at 10:42 AM Matthieu Baerts ***@***.***> wrote: ***@***.**** requested changes on this pull request. ------------------------------ In setup.py <#256 (comment)>: > @@ -50,6 +51,11 @@ "RUSTFLAGS", "" ) +# Generate Rust version file +version_rs_path = pathlib.Path("virtme_ng_init/src/version.rs") +version_rs_path.parent.mkdir(parents=True, exist_ok=True) +version_rs_path.write_text(f'pub const VERSION: &str = "{VERSION}";\n') I don't know Rust well, (maybe @arighi <https://github.com/arighi> can help here? :) ) but I think the idea is to add a build.rs file in virtme_ng_init/ that will execute python3 virtme_ng/version.py and set a build env var: // build.rsuse std::process::Command;fn main() { // note: add error checking yourself. let output = Command::new("python3").args(&["virtme_ng/version.py"]).output().unwrap(); let version = String::from_utf8(output.stdout).unwrap(); println!("cargo:rustc-env=VNG_VERSION={}", version);} Then in main.rs, you can use env!("VNG_VERSION") Source: https://stackoverflow.com/a/44407625

This is pretty slick, and thanks for the link. it has git derived env VERSION, one might expect it to be a quite reliable setting on github :-)

…

— Reply to this email directly, view it on GitHub <#256 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAUBQ7BZVDVBYOMATFDWF32YKTITAVCNFSM6AAAAABZJZUI5OVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDONBXGQ3DMMRYHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

matttbe · 2025-04-07T19:13:09Z

can we depend upon package variables ?

That's different, that will be the version of the init program, no?

Maybe we could also set an env var containing VERSION at build time in setup.py and use it in build.rs?

jimc force-pushed the pid-gt-1 branch 2 times, most recently from 66bd4a8 to 0e4a0df Compare March 19, 2025 05:01

jimc force-pushed the pid-gt-1 branch 3 times, most recently from c3ec9be to 8061617 Compare March 28, 2025 04:10

matttbe reviewed Mar 28, 2025

View reviewed changes

jimc force-pushed the pid-gt-1 branch 2 times, most recently from c60e63d to cd8d9ad Compare April 7, 2025 14:46

jimc force-pushed the pid-gt-1 branch from cd8d9ad to abf3423 Compare April 7, 2025 14:57

matttbe requested changes Apr 7, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

virtme-ng-init: add some useful info when PID>1 #256

virtme-ng-init: add some useful info when PID>1 #256

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

virtme-ng-init: add some useful info when PID>1 #256

Are you sure you want to change the base?

virtme-ng-init: add some useful info when PID>1 #256

Uh oh!

Conversation

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!