-
Notifications
You must be signed in to change notification settings - Fork 64
virtme-ng-init: add some useful info when PID>1 #256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
jimc
wants to merge
1
commit into
arighi:main
Choose a base branch
from
jimc:pid-gt-1
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
8000
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If that's not easily possible, an env var could be passed to the VM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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::versio 8000 n::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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know Rust well, (maybe @arighi can help here? :) ) but I think the idea is to add a
build.rs
file invirtme_ng_init/
that will executepython3 virtme_ng/version.py
and set a build env var:Then in
main.rs
, you can useenv!("VNG_VERSION")
Source: https://stackoverflow.com/a/44407625