Update clusty to v1.1.4 #52217
Update clusty to v1.1.4 #52217
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThe changes in this pull request involve multiple updates to the The Possibly related PRs
Suggested labels
Warning Rate limit exceeded@mencian has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 3 minutes and 59 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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 (4)
recipes/clusty/build.sh (2)
2-3: Consider using modern shell syntaxThe system detection logic is correct, but consider using the modern
$()command substitution syntax instead of backticks.-uname_S=`uname -s 2>/dev/null || echo not` +uname_S=$(uname -s 2>/dev/null || echo not)
5-6: Quote variables to handle paths with spacesWhile the LDFLAGS setup is correct, it's safer to quote variables to handle potential spaces in paths.
-export LDFLAGS="${LDFLAGS} -L${PREFIX}/lib" +export LDFLAGS="${LDFLAGS} -L'${PREFIX}/lib'"recipes/clusty/meta.yaml (2)
28-30: Consider enhancing test coverageWhile the basic smoke test is good, consider adding more comprehensive tests such as:
- Verifying help output (
clusty --help)- Testing with a small sample dataset
- Checking version output (
clusty --version)
46-47: Consider adding source hashWhile skipping the hash lint is common with git sources, consider adding a source hash for better reproducibility:
source: sha256: <hash>
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
recipes/clusty/build.sh(1 hunks)recipes/clusty/buildfixes.patch(1 hunks)recipes/clusty/meta.yaml(1 hunks)
🧰 Additional context used
🪛 yamllint
recipes/clusty/meta.yaml
[error] 1-1: syntax error: found character '%' that cannot start any token
(syntax)
🔇 Additional comments (9)
recipes/clusty/build.sh (2)
13-14: LGTM! Installation commands follow best practices
The installation commands properly create the target directory and set appropriate executable permissions (0755) with verbose output for better debugging.
7-11: Verify the platform-specific LEIDEN flag difference
The build command omits LEIDEN=true for Darwin (macOS) systems while including it for others. This difference might lead to inconsistent functionality across platforms.
recipes/clusty/buildfixes.patch (2)
8-10: LGTM! Removal of -static-libgcc aligns with macOS best practices.
The removal of -static-libgcc from the macOS linker flags is correct as static linking of the GCC runtime library is not recommended on macOS and can lead to integration issues. The remaining flags maintain the necessary optimizations and C++17 standard support.
7-13: Verify if this change addresses known issues.
Let's check if this change resolves any existing problems with the package on macOS.
✅ Verification successful
Removal of -static-libgcc on macOS is appropriate
The change is correct and justified for the following reasons:
- The patch is specifically applied only on macOS (
[osx]in meta.yaml) - Static linking of libgcc is not typically recommended on macOS and can cause issues
- The build script already has separate handling for Darwin/macOS builds
- The change maintains consistency with other platform-specific compilation flags
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for related issues or discussions about macOS build problems
# Search for related issues in bioconda-recipes
gh issue list -R bioconda/bioconda-recipes --search "clusty macos static-libgcc" --state all
# Search for related pull requests
gh pr list -R bioconda/bioconda-recipes --search "clusty macos static-libgcc" --state all
# Check if there are any existing build logs showing failures related to static-libgcc
gh run list -R bioconda/bioconda-recipes --workflow build-linux --branch "clusty" -L 10
Length of output: 321
Script:
#!/bin/bash
# Let's check for any build-related files or discussions about macOS compilation
# in the repository and related issues
# Search for any Makefile or build-related files mentioning static-libgcc
rg -l "static-libgcc" --type make
# Search for any discussions about macOS compilation issues
rg -i "macos|darwin" --type md
# Check if there are any other Makefiles with similar patterns
fd Makefile --type f --exec grep -l "Darwin" {} \;
# Look for any build logs or documentation
fd -e log -e md -e txt --exec grep -il "static-libgcc" {} \;
Length of output: 550
Script:
#!/bin/bash
# Let's check the specific recipe directory and patch file content
# Check the content of the patch file
cat recipes/clusty/buildfixes.patch
# Look for any meta.yaml or build scripts in the recipe
cat recipes/clusty/meta.yaml 2>/dev/null
cat recipes/clusty/build.sh 2>/dev/null
# Check if there are any similar Darwin/macOS specific build flags in other recipes
rg "ifeq.*Darwin" --type make -A 3
Length of output: 2229
recipes/clusty/meta.yaml (5)
1-6: LGTM! Good use of Jinja2 variables
The package metadata is well-structured with proper use of variables for name and version.
🧰 Tools
🪛 yamllint
[error] 1-1: syntax error: found character '%' that cannot start any token
(syntax)
19-26: LGTM! Build dependencies are appropriate
The added build dependencies (cmake, flex, bison) are appropriate for a C/C++ project that requires parsing capabilities.
33-39: LGTM! Improved metadata quality
Good improvements:
- Updated to SPDX license identifier
- Added development and documentation URLs
9-11: Verify the impact of relaxed version pinning
The change from strict pinning (x.x.x) to more relaxed pinning (x) could potentially lead to ABI compatibility issues. According to Bioconda guidelines, this should align with known breakage patterns.
16-17: LGTM! Verify the patch file contents
The macOS-specific patch is correctly configured with conditional selector.
✅ Verification successful
Patch file correctly removes static linking on macOS as intended
The patch file correctly modifies the makefile to remove -static-libgcc flag from macOS build configuration, which is a common requirement for macOS builds. Similar patches exist in other recipes (graphmap, regenie, star, meraculous, mantis) dealing with static linking adjustments, confirming this is a standard practice.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check the contents of the patch file
cat recipes/clusty/buildfixes.patch
# Look for similar patches in other recipes for reference
fd -g "*.patch" recipes/ --exec grep -l "static-libgcc"
Length of output: 975
Describe your pull request here
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>.