-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Add recipe for rukki v0.3.0 #51115
Add recipe for rukki v0.3.0 #51115
Conversation
📝 WalkthroughWalkthroughThis pull request introduces two new files within the Changes
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 (
|
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.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
recipes/rukki/build.sh (2)
1-1
: Consider adding thepipefail
option to the shebang.The current shebang includes good practices with
-eu
, but the-o
option is incomplete. Consider updating it to includepipefail
:-#!/bin/bash -euo +#!/bin/bash -euo pipefailThis will cause the script to exit if any command in a pipeline fails, not just the last one.
5-5
: Approve cargo install command with a suggestion.The
cargo install
command looks good and uses appropriate flags. However, to ensure consistency across builds, consider specifying the version explicitly:-cargo install --verbose --path . --root "${PREFIX}" +cargo install --verbose --path . --root "${PREFIX}" --version 0.3.0This change will help prevent potential issues if the local repository contains multiple versions or if the version in Cargo.toml doesn't match the intended release.
recipes/rukki/meta.yaml (1)
23-25
: LGTM: Basic test command is presentThe test command
rukki --help
is a good start to verify that the package is installed and executable.Consider adding more comprehensive test commands to ensure the functionality of key features. For example:
test: commands: - rukki --help - rukki --version - rukki --list-commands # if such an option exists
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
- recipes/rukki/build.sh (1 hunks)
- recipes/rukki/meta.yaml (1 hunks)
🧰 Additional context used
🪛 Shellcheck
recipes/rukki/build.sh
[warning] 4-4: RUST_BACKTRACE appears unused. Verify use (or export if used externally).
(SC2034)
🪛 yamllint
recipes/rukki/meta.yaml
[error] 1-1: syntax error: found character '%' that cannot start any token
(syntax)
🔇 Additional comments (8)
recipes/rukki/build.sh (1)
4-4
:⚠️ Potential issueReconsider the RUST_BACKTRACE setting.
The
RUST_BACKTRACE=1
setting is not exported and won't affect thecargo install
command. Additionally, enabling backtraces might not be desirable for a production build. Consider one of the following options:
- Remove the line if backtraces are not needed:
-RUST_BACKTRACE=1
- Export the variable if backtraces are required:
-RUST_BACKTRACE=1 +export RUST_BACKTRACE=1
- Pass it directly to the cargo command if needed only for the installation:
-RUST_BACKTRACE=1
(And update the cargo command accordingly)
To check if RUST_BACKTRACE is used elsewhere in the recipe, run:
✅ Verification successful
<!-- [monologue] [task verify_review_comment_1/1] [observations] - The `RUST_BACKTRACE=1` is set in `recipes/rukki/build.sh` on line 4. - The shell script executed (`rg --type yaml --type sh 'RUST_BACKTRACE' recipes/rukki`) only found this single occurrence. - There are no exports of `RUST_BACKTRACE`, and no other usages are detected in the repository. [analysis] - Since `RUST_BACKTRACE=1` is not exported or used elsewhere, it likely has no effect on the build or install processes. - This suggests that the setting might be unnecessary and could be removed to clean up the build script. [actions] - Conclude that the `RUST_BACKTRACE=1` line can be safely removed if backtraces are not needed. - Alternatively, if backtraces are desired during the build process for debugging, the variable should be exported to ensure it's available to subprocesses. -->RUST_BACKTRACE Setting Verification
The
RUST_BACKTRACE=1
line inrecipes/rukki/build.sh
is not utilized elsewhere in the codebase and is not exported.
If backtraces are not needed:
Remove the line to clean up the build script.-RUST_BACKTRACE=1
If backtraces are required for debugging:
Export the variable to ensure it's available during the build process.-RUST_BACKTRACE=1 +export RUST_BACKTRACE=1🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for RUST_BACKTRACE usage in recipe files rg --type yaml --type sh 'RUST_BACKTRACE' recipes/rukkiLength of output: 95
🧰 Tools
🪛 Shellcheck
[warning] 4-4: RUST_BACKTRACE appears unused. Verify use (or export if used externally).
(SC2034)
recipes/rukki/meta.yaml (7)
1-6
: LGTM: Package section is well-definedThe package section correctly defines the name and version using Jinja2 variables, which is a good practice for maintainability.
🧰 Tools
🪛 yamllint
[error] 1-1: syntax error: found character '%' that cannot start any token
(syntax)
12-15
: LGTM: Build section is well-configuredThe build section is correctly set up:
- Build number 0 is appropriate for a new recipe.
- The use of
run_exports
withpin_subpackage
is excellent for maintaining ABI compatibility.This configuration aligns well with the PR objectives of preventing API, ABI, and CLI breakage issues.
35-38
: LGTM: Additional platforms are specifiedThe inclusion of linux-aarch64 and osx-arm64 as additional platforms is excellent. This ensures broader compatibility, which is particularly valuable in the bioinformatics field.
1-2
: Note on yamllint warningThe yamllint tool reports a syntax error for the '%' character at the beginning of the file. This is a false positive. The '%' is part of the Jinja2 template syntax, which is correctly used here to define variables for the package name and version. This is a common and recommended practice in Conda recipes.
🧰 Tools
🪛 yamllint
[error] 1-1: syntax error: found character '%' that cannot start any token
(syntax)
27-33
: LGTM: About section is comprehensiveThe about section provides all necessary information including home page, license, summary, and URLs for documentation and development.
Please verify the "Public Domain" license. This is an unusual license for software. You can run the following script to check the license file:
#!/bin/bash # Description: Check the content of the license file # Test: Display the content of the README.licenses file echo "Content of README.licenses:" cat README.licenses echo "Please confirm that the license is indeed Public Domain and not a more common open-source license."
17-21
: LGTM: Build requirements are appropriateThe build requirements (C++ compiler, Rust compiler, and make) seem suitable for a Rust project with C++ components.
Please verify that there are no missing runtime dependencies. You can run the following script to check the project's Cargo.toml file for potential runtime dependencies:
#!/bin/bash # Description: Check for potential runtime dependencies in Cargo.toml # Test: Search for dependencies in Cargo.toml echo "Potential runtime dependencies:" rg '^\[dependencies\]' -A 10 Cargo.toml echo "If any non-dev dependencies are found, consider adding them to the 'run' section of the requirements."
8-10
: LGTM: Source section is correctly definedThe source URL and SHA256 checksum are properly specified. This ensures integrity and reproducibility of the package.
Please verify that v0.3.0 is the latest stable version of rukki. You can run the following script to check:
✅ Verification successful
Please run the following script to verify if
v0.3.0
is the latest stable release ofrukki
:
Verified: The recipe is using the latest stable version of rukki
v0.3.0 is confirmed as the latest stable release, ensuring the recipe is up-to-date.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if v0.3.0 is the latest release of rukki # Test: Fetch the latest release tag from GitHub latest_tag=$(gh api repos/marbl/rukki/releases/latest --jq .tag_name) echo "Latest release tag: $latest_tag" if [ "$latest_tag" = "v0.3.0" ]; then echo "The recipe is using the latest stable version." else echo "A newer version is available. Consider updating the recipe." fiLength of output: 435
Script:
# #!/bin/bash # Description: Check if v0.3.0 is the latest release of rukki using curl and jq # Fetch the latest release tag from GitHub latest_tag=$(curl -s https://api.github.com/repos/marbl/rukki/releases/latest | jq -r .tag_name) echo "Latest release tag: $latest_tag" if [ "$latest_tag" = "v0.3.0" ]; then echo "The recipe is using the latest stable version." else echo "A newer version is available. Consider updating the recipe to $latest_tag." fiLength of output: 298
Describe your pull request here
Please read the guidelines for Bioconda recipes before opening a pull request (PR).
General instructions
@BiocondaBot please add label
command.@bioconda/core
in 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_exports
section 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 eithername
if aname|lower
variable 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 label
please review & merge
label.@BiocondaBot please fetch artifacts
You can use this to test packages locally.
Note that the
@BiocondaBot please merge
command 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>
.Summary by CodeRabbit
New Features
build.sh
for building therukki
package.meta.yaml
file with package metadata, including versioning and source information.Documentation
meta.yaml
file.Testing
rukki --help
.