Add recipe for snpick #52144
Add recipe for snpick #52144
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThe pull request introduces a new Possibly related PRs
Suggested labels
Suggested reviewers
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: 1
🧹 Outside diff range and nitpick comments (3)
recipes/snpick/meta.yaml (3)
13-29: Add skip section for unsupported platforms.Consider adding a skip section to explicitly define unsupported platforms:
build: number: 0 + skip: true # [win] script: |
30-44: Consider adding common CI dependencies.For better CI compatibility, consider adding these common dependencies:
build: - {{ compiler('rust') }} - pkg-config + - make + - cmake
50-60: Consider adding more documentation resources.All documentation links currently point to GitHub. Consider adding:
- A dedicated documentation site (e.g., ReadTheDocs)
- Usage examples
- Citation information
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
recipes/snpick/meta.yaml(1 hunks)
🧰 Additional context used
🪛 yamllint
recipes/snpick/meta.yaml
[error] 1-1: syntax error: found character '%' that cannot start any token
(syntax)
🔇 Additional comments (4)
recipes/snpick/meta.yaml (4)
1-8: LGTM! Package metadata follows best practices.
The use of Jinja2 variables for package name, version, and checksum makes the recipe maintainable.
🧰 Tools
🪛 yamllint
[error] 1-1: syntax error: found character '%' that cannot start any token
(syntax)
61-70: LGTM! Comprehensive metadata provided.
The extra section properly defines supported platforms, maintainers, and relevant bioinformatics categories.
26-26: Verify cargo installation flags.
The --locked flag ensures reproducible builds, which is good. However, let's verify if the package has a Cargo.lock file.
✅ Verification successful
Using --locked flag is consistent with best practices
The --locked flag is consistently used across multiple Rust package installations in the repository, which is a good practice for reproducible builds. While we couldn't directly verify the presence of Cargo.lock in the source repository, the usage pattern in similar recipes suggests this is a standard approach for Rust package installations in this ecosystem.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for Cargo.lock in the source repository
URL="https://github.com/PathoGenOmics-Lab/snpick"
# Check if Cargo.lock exists in the repository
gh api repos/PathoGenOmics-Lab/snpick/contents/Cargo.lock --jq '.name'
Length of output: 217
Script:
#!/bin/bash
# Let's verify if the Cargo.lock exists in the repository and check its content
rg -l "Cargo.lock"
# Also check if there's any mention of --locked flag in build scripts or documentation
rg --type yaml --type md "\-\-locked"
Length of output: 692
9-12: Verify source URL accessibility and checksum.
Let's ensure the source URL is accessible and the checksum matches.
✅ Verification successful
Source URL and release are valid and accessible
The verification confirms:
- Repository exists and is not archived
- Release 1.0.0 exists with a valid tarball URL
- The source URL in meta.yaml correctly points to the release tarball
- The URL is accessible and returns a valid gzipped tarball
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify source URL accessibility and checksum
URL="https://github.com/PathoGenOmics-Lab/snpick/archive/refs/tags/1.0.0.tar.gz"
EXPECTED_SHA="6a5ae16a65c92c90ecf710c4d53afa0e3a76b7a43554c52e48cda843f7e20744"
# Check if URL is accessible
if curl --output /dev/null --silent --head --fail "$URL"; then
echo "URL is accessible"
else
echo "URL is not accessible"
exit 1
fi
Length of output: 217
Script:
#!/bin/bash
# Let's verify the repository and release existence first
gh repo view PathoGenOmics-Lab/snpick --json name,isArchived,defaultBranch
gh release view 1.0.0 --repo PathoGenOmics-Lab/snpick --json name,tagName,url,isLatest
# Then verify the specific tarball URL
curl -I "https://github.com/PathoGenOmics-Lab/snpick/archive/refs/tags/1.0.0.tar.gz"
Length of output: 5819
Script:
#!/bin/bash
# Let's try with corrected JSON fields and focus on getting release information
gh repo view PathoGenOmics-Lab/snpick --json name,isArchived
gh release view 1.0.0 --repo PathoGenOmics-Lab/snpick --json tagName,tarballUrl
# Let's also check the final redirect URL
curl -IL "https://github.com/PathoGenOmics-Lab/snpick/archive/refs/tags/1.0.0.tar.gz"
Length of output: 5307
| test: | ||
| commands: | ||
| - snpick --help | ||
| - snpick --version | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Enhance test coverage with functional tests.
Current tests only verify basic command availability. Consider adding functional tests:
test:
commands:
- snpick --help
- snpick --version
+ # Add functional test with minimal example
+ - snpick --input test.fasta --output test.vcf
+ files:
+ - test.fastaWould you like me to help create a minimal test dataset and corresponding test commands?
Committable suggestion skipped: line range outside the PR's diff.
|
@BiocondaBot please add label |
|
@BiocondaBot please fetch artifacts |
|
Package(s) built are ready for inspection:
Docker image(s) built:
|
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>.