Enforce openjdk 21 for hmftools, part 2/4 (Cuppa, Esvee, Isofox, Lilac) #52268
Conversation
📝 WalkthroughWalkthroughThis pull request includes modifications to the 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: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
recipes/hmftools-cuppa/meta.yaml(2 hunks)recipes/hmftools-esvee/meta.yaml(1 hunks)recipes/hmftools-isofox/meta.yaml(1 hunks)recipes/hmftools-lilac/meta.yaml(1 hunks)
🔇 Additional comments (7)
recipes/hmftools-lilac/meta.yaml (2)
14-14: LGTM: Build number increment is appropriate
The build number increment is correct as per conda-build guidelines when making package modifications.
21-21: Verify LILAC compatibility with OpenJDK 21
While the constraint change aligns with the PR objective, we should verify:
- That LILAC has been tested and is compatible with OpenJDK 21
- That this version constraint won't cause issues with downstream dependencies
recipes/hmftools-esvee/meta.yaml (1)
15-15: LGTM! Build number increment is appropriate.
The build number increment follows conda packaging guidelines for dependency changes.
recipes/hmftools-isofox/meta.yaml (1)
14-14: LGTM! Build number increment is appropriate.
The build number increment is correct for this package update.
recipes/hmftools-cuppa/meta.yaml (3)
15-15: LGTM: Build number increment is appropriate
Build number increment is correct for the dependency constraint update.
16-18: LGTM: Proper dependency pinning configuration
The run_exports section correctly pins the package version using max_pin="x.x", which helps prevent API/ABI breakage in downstream dependencies.
Line range hint 26-30: Verify compatibility of Python/R dependency versions
The package has specific version constraints for scientific computing packages:
- Python 3.11
- numpy >=1.24
- pandas 2.0.*
- scikit-learn 1.3.0
Please ensure these versions are tested together in CI to verify compatibility.
Let's check for any existing test configurations:
✅ Verification successful
Dependencies are verified through bioconda's CI pipeline
Based on the CI configuration evidence:
- The package undergoes automated testing through bioconda-utils in GitHub Actions
- Dependencies are tested during build and test phases using
--mulled-testflag - Both Linux and macOS builds verify the package compatibility
- The package is built and tested against the specified Python/R dependency versions
The version constraints are appropriate and verified through the bioconda CI pipeline, which includes container-based testing to ensure all dependencies work together.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Look for test configurations and CI settings
# Expected: Test configurations that verify dependency compatibility
# Search for test configurations
fd "test" recipes/hmftools-cuppa/
Length of output: 33
Script:
#!/bin/bash
# Let's check for any CI configurations and test files in the repository root
fd "\.ya?ml$" .github/workflows/
# Check if there are any test files for bioconda recipes
fd "test" bioconda-recipes/
# Look for any conda build or test configurations
rg -A 5 "test:" recipes/hmftools-cuppa/
Length of output: 766
Script:
#!/bin/bash
# Let's check the CI workflow files for conda/dependency testing
rg -A 10 "conda" .github/workflows/PR.yml
# Check if there are any specific test requirements for recipes
rg "requirements" recipes/hmftools-cuppa/meta.yaml
# Look for any build configurations that might verify dependencies
rg "build:" recipes/hmftools-cuppa/meta.yaml -A 5
Length of output: 7233
| run_exports: | ||
| - {{ pin_subpackage("hmftools-esvee", max_pin="x.x") }} | ||
|
|
||
| requirements: | ||
| run: | ||
| - openjdk >=8 | ||
| - openjdk >=8,<=21 |
There was a problem hiding this comment.
💡 Codebase verification
OpenJDK constraint inconsistency found across hmftools packages
The OpenJDK version constraints are not consistent across the hmftools packages:
- Most packages use only
>=8 - Some packages (cuppa, esvee, lilac, isofox, redux) use
>=8,<=21 - One package (sage) uses
>=9
This inconsistency should be addressed to ensure uniform Java version requirements across the hmftools suite.
🔗 Analysis chain
Verify OpenJDK constraint consistency across hmftools packages.
The OpenJDK constraint change to >=8,<=21 aligns with the PR objective. Let's verify this constraint is consistent across related packages.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check OpenJDK constraints in all hmftools packages
# Expected: All should use '>=8,<=21' for consistency
echo "Checking OpenJDK constraints in hmftools packages..."
fd -e yaml -e yml meta.yaml$ recipes/hmftools- --exec grep -H "openjdk" {}
Length of output: 298
Script:
#!/bin/bash
# Let's try a different approach using ripgrep to find hmftools recipes
echo "Finding hmftools recipes and their OpenJDK requirements..."
rg -l "hmftools" recipes/ | grep "meta.yaml" | xargs rg "openjdk" -C 2
Length of output: 5815
| run_exports: | ||
| - {{ pin_subpackage('hmftools-isofox', max_pin="x.x") }} | ||
|
|
||
| requirements: | ||
| run: | ||
| - openjdk >=8 | ||
| - openjdk >=8,<=21 |
There was a problem hiding this comment.
💡 Codebase verification
OpenJDK constraints are inconsistent across hmftools packages
The verification reveals inconsistencies in OpenJDK version constraints across hmftools packages:
- Most packages use
openjdk >=8without an upper bound - Only 5 packages (redux, lilac, isofox, esvee, cuppa) use
openjdk >=8,<=21 - One package (sage) uses
openjdk >=9
These inconsistencies should be addressed to maintain uniformity across the hmftools suite.
🔗 Analysis chain
Verify OpenJDK constraint consistency across hmftools packages.
The OpenJDK constraint change to >=8,<=21 aligns with the PR objective. Let's verify this constraint is consistent across other hmftools packages.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check OpenJDK constraints across hmftools packages
# Expected: All hmftools packages should have the same OpenJDK constraint
echo "Checking OpenJDK constraints in hmftools packages:"
fd '^meta.yaml$' recipes/hmftools- --exec grep -H 'openjdk' {}
Length of output: 280
Script:
#!/bin/bash
# Let's try a different approach to find hmftools packages
echo "Finding all hmftools meta.yaml files:"
fd 'meta.yaml$' | grep 'hmftools'
echo -e "\nChecking OpenJDK constraints in these files:"
fd 'meta.yaml$' | grep 'hmftools' | xargs grep -H 'openjdk'
Length of output: 2282
| @@ -22,7 +22,7 @@ requirements: | |||
| - r-base >=4.2,<4.3.0a0 | |||
| - unzip | |||
| run: | |||
| - openjdk >=8 | |||
| - openjdk >=8,<=21 | |||
There was a problem hiding this comment.
💡 Codebase verification
OpenJDK version constraints are inconsistent across hmftools packages
The version constraint >=8,<=21 is only used in 5 packages (cuppa, isofox, esvee, lilac, redux) while most other packages use >=8 and one package (sage) uses >=9. This inconsistency suggests that the upper bound constraint is a recent addition and not yet standardized across all hmftools packages.
>=8,<=21: cuppa, isofox, esvee, lilac, redux>=8: amber, bam-tools, chord, cobalt, gripss, linx, mark-dups, neo, orange, pave, peach, protect, purple, rose, sigs, sv-prep, virus-interpreter>=9: sage
🔗 Analysis chain
Verify if the version range meets the enforcement requirement
The current constraint >=8,<=21 allows any OpenJDK version from 8 to 21. If the goal is to strictly enforce OpenJDK 21, consider using ==21 instead. However, if backward compatibility is needed, the current range is appropriate.
Let's check if other hmftools packages use the same constraint:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check OpenJDK constraints in other hmftools packages
# Expected: Similar version constraints across hmftools packages
# Search for openjdk constraints in hmftools recipes
rg "openjdk.*[0-9]" recipes/hmftools-*
Length of output: 1792
|
@BiocondaBot please add label |
luan-n-nguyen
changed the title
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>.