Update core-snp-filter: add aarch64/arm64 builds #52255
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThe pull request modifies the Possibly related PRs
Suggested labels
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
recipes/core-snp-filter/meta.yaml (1)
Line range hint
26-29: Consider adding ARM-specific test casesWhile the basic test command looks good, consider adding specific test cases to verify functionality on ARM platforms.
Would you like help creating additional test cases for ARM platforms?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
recipes/core-snp-filter/meta.yaml(2 hunks)
🔇 Additional comments (3)
recipes/core-snp-filter/meta.yaml (3)
12-14: LGTM! Build configuration looks good.
The build number increment and run_exports pinning are correctly configured to maintain package compatibility.
37-40: Verify ARM platform compatibility
The addition of ARM platform support needs verification of build system compatibility.
Let's check for platform-specific code and build system support:
Line range hint 16-23: Verify Python dependency removal impact
The removal of Python runtime dependency appears intentional and aligns with the PR objectives. The package seems to be a pure C++/Rust implementation.
Let's verify there are no Python dependencies:
✅ Verification successful
Python dependency removal is safe
The verification confirms that the core-snp-filter package:
- Has no Python files or Python-related code
- Uses only Rust for building (
cargo install) - Contains no Python imports or dependencies in its build scripts
- Has a pure native implementation without Python bindings
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any Python imports or dependencies in the source code
# Search for Python file extensions
echo "Checking for Python files:"
fd -e py -e pyw
# Search for Python shebangs
echo "Checking for Python shebangs:"
rg "^#!.*python"
# Search for Python imports in build scripts
echo "Checking build scripts for Python usage:"
rg -l "import.*python|from.*python" -g "CMakeLists.txt" -g "Makefile" -g "build.rs"
Length of output: 16446
Script:
#!/bin/bash
# Let's check for Python dependencies specifically in the core-snp-filter recipe and its source code
# Check for Python imports in build.sh and any other recipe files
echo "Checking recipe files for Python usage:"
rg -l "python" recipes/core-snp-filter/
# Check for Python dependencies in source files
echo "Checking source files for Python imports:"
rg "import|from.*import" recipes/core-snp-filter/
# Check if there are any Python files in the recipe directory
echo "Checking for Python files in recipe:"
fd -e py -e pyw recipes/core-snp-filter/
# Check if build.sh or install scripts use Python
echo "Checking build scripts for Python usage:"
cat recipes/core-snp-filter/build.sh
Length of output: 1057
Please read the guidelines for Bioconda recipes before opening a pull request (PR).
General instructions
@BiocondaBot please add labelcommand.@bioconda/corein a comment.Instructions for avoiding API, ABI, and CLI breakage issues
Conda is able to record and lock (a.k.a. pin) dependency versions used at build time of other recipes.
This way, one can avoid that expectations of a downstream recipe with regards to API, ABI, or CLI are violated by later changes in the recipe.
If not already present in the meta.yaml, make sure to specify
run_exports(see here for the rationale and comprehensive explanation).Add a
run_exportssection like this:with
...being one of:{{ pin_subpackage("myrecipe", max_pin="x") }}{{ pin_subpackage("myrecipe", max_pin="x.x") }}{{ pin_subpackage("myrecipe", max_pin="x.x") }}(in such a case, please add a note that shortly mentions your evidence for that){{ pin_subpackage("myrecipe", max_pin="x.x.x") }}(in such a case, please add a note that shortly mentions your evidence for that){{ pin_subpackage("myrecipe", max_pin=None) }}while replacing
"myrecipe"with eithernameif aname|lowervariable is defined in your recipe or with the lowercase name of the package in quotes.Bot commands for PR management
Please use the following BiocondaBot commands:
Everyone has access to the following BiocondaBot commands, which can be given in a comment:
@BiocondaBot please update@BiocondaBot please add labelplease review & mergelabel.@BiocondaBot please fetch artifactsYou can use this to test packages locally.
Note that the
@BiocondaBot please mergecommand is now depreciated. Please just squash and merge instead.Also, the bot watches for comments from non-members that include
@bioconda/<team>and will automatically re-post them to notify the addressed<team>.