-
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 sopa package #51367
Add sopa package #51367
Conversation
📝 WalkthroughWalkthroughThe pull request introduces a new YAML configuration file for the "sopa" package, specifying its metadata and build specifications. The package is named "sopa" with a version of "1.1.5". It includes a source URL pointing to a tarball on PyPI, along with a SHA256 checksum for verification. The build section defines an entry point for the application, indicating that it can be accessed via 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)
sopa/meta.yaml (3)
19-52
: Requirements section is well-structured, but consider reviewing version constraints.The requirements section is well-organized with separate host and run requirements. The use of
run_constrained
for optional dependencies is a good practice. However, some dependencies have very specific version constraints, which might lead to conflicts or maintenance issues in the future.Consider reviewing and possibly relaxing some version constraints, especially for dependencies that are not directly related to the core functionality of the package. For example:
- - flake8 <8.0.0,>=7.0.0 + - flake8 >=7.0.0,<8.0.0 - - snakemake >=7.32.4,<8.0.0,<8.1.3 + - snakemake >=7.32.4,<8.2.0 - - pulp >=2.3.1,<3.0.0,<2.8 + - pulp >=2.3.1,<3.0.0This will make the package more flexible and easier to maintain in the long run.
53-60
: Test section is good, but consider adding more comprehensive tests.The test section includes basic checks like importing the package, verifying dependencies with
pip check
, and running the CLI help command. These are good starting points.To improve the test coverage, consider adding more comprehensive tests:
- Add unit tests for core functionalities.
- Include integration tests if applicable.
- Test with different input data or configurations.
Example addition:
commands: - pip check - sopa --help - python -m pytest tests/This assumes you have a
tests/
directory with pytest-compatible tests. If not, I can help you set up a basic test structure.
68-70
: Extra section is good, but consider adding more maintainers.The extra section correctly lists the recipe maintainer. However, having only one maintainer (quentinblampey) might be a potential single point of failure for package maintenance.
Consider adding more maintainers to ensure continued support and maintenance of the package. This can be done by adding more GitHub usernames to the list:
extra: recipe-maintainers: - quentinblampey - another_maintainer - yet_another_maintainer
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- sopa/meta.yaml (1 hunks)
🧰 Additional context used
🪛 yamllint
sopa/meta.yaml
[error] 1-1: syntax error: found character '%' that cannot start any token
(syntax)
🔇 Additional comments (4)
sopa/meta.yaml (4)
1-10
: LGTM: Package and source information looks good.The package name and version are correctly defined using Jinja2 variables, which is a good practice for maintainability. The source URL follows the PyPI convention, and the SHA256 checksum is provided for integrity verification.
🧰 Tools
🪛 yamllint
[error] 1-1: syntax error: found character '%' that cannot start any token
(syntax)
62-66
: LGTM: About section is well-defined.The about section provides all necessary information including the home page, a concise summary, and correct license details. The BSD-3-Clause license is appropriately specified, and the license file is correctly referenced.
1-2
: Note: Ignore yamllint syntax error for '%' character.The yamllint tool reported a syntax error for the '%' character at the beginning of the file. This is a false positive. The '%' character is part of the Jinja2 template syntax, which is correctly used here and follows Conda packaging best practices.
🧰 Tools
🪛 yamllint
[error] 1-1: syntax error: found character '%' that cannot start any token
(syntax)
12-17
: Build section looks good, but consider installation flags.The build section is well-defined with the correct entry point and
noarch: python
setting. However, the installation script uses--no-deps
and--no-build-isolation
flags, which might cause issues if not handled carefully.Please ensure that all dependencies are correctly specified in the
requirements
section, as--no-deps
will prevent pip from installing or upgrading dependencies. Also, verify that the package doesn't require any build-time dependencies that might be affected by--no-build-isolation
.
@BiocondaBot please add label |
Adding the sopa package to bioconda
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>
.