Update meta-neuro version 1.0.0 #51826
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThe pull request introduces several modifications across three files related to the In The Suggested reviewers
Possibly related PRs
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/meta/conda_build_config.yaml (2)
1-3: Document the purpose and impact of build variants.While the build variants are correctly defined, their purpose and impact on the build process should be documented. This is especially important as these variants appear to be related to the VTK dependency changes mentioned in the package updates.
Consider adding a comment block explaining:
- The purpose of each variant
- Which variant should be used by default
- Any specific requirements for each variant
+# Build variants for meta package: +# - qt: Default variant with Qt support +# - osmesa: Variant for headless rendering support build_variant: - "qt" - "osmesa" # [linux64]
1-4: Consider adding variant-specific dependencies in meta.yaml.Since you've defined build variants that likely correspond to different dependency sets (especially given the VTK-related changes mentioned in the summary), ensure these are properly reflected in the package metadata.
Consider:
- Using
{{ build_variant }}in meta.yaml to conditionally include dependencies- Adding appropriate run_exports sections for each variant
- Documenting the dependency differences between variants in the package description
recipes/meta/meta.yaml (1)
14-15: Addressing package visibility on Bioconda channel.The build number increment should trigger a new package build. However, if visibility issues persist:
- Ensure the package builds successfully on all required platforms
- Verify that the package passes all conda-forge compatibility requirements
- Check if the package needs to be added to specific channel configurations
Consider running
conda build . -c conda-forge -c bioconda --outputlocally to verify the expected package output path.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
recipes/meta/build.sh(3 hunks)recipes/meta/conda_build_config.yaml(1 hunks)recipes/meta/meta.yaml(2 hunks)
🔇 Additional comments (7)
recipes/meta/conda_build_config.yaml (1)
3-3: Verify linux64 platform selector compatibility.
The platform selector for osmesa appears correct, but we should verify its compatibility with the build infrastructure.
✅ Verification successful
Let me gather more information about the build configuration to ensure complete verification.
Platform selector for osmesa is correctly configured and compatible
The verification shows that:
- The
[linux64]selector for osmesa is consistent with the build configuration - The recipe already skips Windows builds with
[win]selector - The build variant is properly referenced in VTK dependencies
- The configuration follows conda-forge's standard platform selector syntax
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for other platform selectors and build variant usage
# to ensure consistency across the recipe
# Check for other platform-specific configurations
echo "Checking for other platform selectors..."
rg "\[linux64\]" recipes/meta/
# Check for build_variant references
echo "Checking for build_variant usage..."
rg "build_variant" recipes/meta/
Length of output: 519
Script:
#!/bin/bash
# Check the complete conda build config and meta.yaml for platform-specific settings
echo "Checking conda_build_config.yaml content..."
cat recipes/meta/conda_build_config.yaml
echo -e "\nChecking meta.yaml content..."
cat recipes/meta/meta.yaml
# Look for any other platform selectors in the codebase
echo -e "\nChecking for other platform selectors..."
rg "\[(linux|win|osx|unix|aarch64|ppc64le|x86_64)" recipes/meta/
Length of output: 2446
recipes/meta/build.sh (3)
23-24: LGTM! Build commands are properly configured.
The build commands are well structured with:
- Parallel builds using
${CPU_COUNT} - Verbose output for better debugging
- Proper error handling through
set -e
27-28: LGTM! Pip install command follows Conda best practices.
The pip install command is correctly configured with:
--no-depsflag to prevent pip from managing dependencies (handled by conda)-vvfor verbose output- Proper error handling through
set -e
2-2: Verify the shell options setting in Bioconda recipes.
The addition of set -ex improves debugging by showing commands and failing fast on errors. Let's verify this follows Bioconda's best practices.
✅ Verification successful
Let me analyze the results from the shell script. The search shows extensive usage of set -ex across many build scripts in the Bioconda repository, particularly in recipe build scripts. This is a common and recommended practice in Bioconda for several reasons:
set -e: Ensures the build fails fast if any command failsset -x: Provides verbose output useful for debugging build issues
The use of set -ex in build.sh is consistent with Bioconda's best practices and improves build reliability and debugging.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if other Bioconda recipes use similar shell options
# Test: Search for shell options in other build.sh files
# Expect: Similar usage of set -ex in other recipes
# Look for shell options in other build.sh files
rg -l 'set -[ex]' recipes/*/build.sh
Length of output: 217946
recipes/meta/meta.yaml (3)
14-15: LGTM! Build configuration changes look good.
The build number increment and Windows skip condition are appropriate for this update.
39-40: Verify removal of runtime dependencies.
The AI summary indicates that several dependencies were removed (hdf5, vtk-base, vtk-io-ffmpeg). Please verify that these are no longer required at runtime.
#!/bin/bash
# Search for usage of removed dependencies in source code
echo "Checking for VTK usage..."
rg -i "import.*vtk|from.*vtk" --type py
echo "Checking for HDF5 usage..."
rg -i "import.*h5py|from.*h5py|import.*hdf5|from.*hdf5" --type py26-26: Verify compatibility with Python 3.10 and 3.11.
The Python version constraint has been broadened from <3.10 to <3.12. Please ensure that the package has been tested with Python 3.10 and 3.11.
✅ Verification successful
Based on the code inspection results, I don't see any Python version-specific code or dependencies that would prevent compatibility with Python 3.10 and 3.11. The setup.py files shown use basic Python functionality and don't indicate any version restrictions. Additionally, there are no uses of async/await syntax or other Python 3.10+ specific features that would cause issues.
The Python version constraint change from <3.10 to <3.12 appears safe.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if there are any Python version-specific code or known issues
rg -i "python\s*(2|3\.[0-9]+)" --type py
Length of output: 233
Script:
#!/bin/bash
# Check for Python version-specific imports or syntax
rg -i "python\s*(2|3\.[0-9]+)" --type-add 'pyall:*.{py,pyx,pxd}' --type pyall
# Check setup.py, pyproject.toml, or similar for Python requirements
fd -e py -e toml -e cfg -e ini "setup|pyproject|requirements" --exec cat {}
# Look for CI configuration files that might specify Python versions
fd -g "*ci*.yml" -g "*workflow*.yml" -g ".github/workflows/*.yml" --exec cat {}
Length of output: 5073
Script:
#!/bin/bash
# Check for test files that might indicate Python version compatibility
rg -i "test|pytest" --type py -l | xargs cat
# Check for any Python version-specific code in the source files
fd -e py -e pyx -e pxd . --exec grep -l -i "async|await|f\"|typing\." {} \;
# Look for README or documentation files that might mention Python compatibility
fd -e md -e rst "README|INSTALL|CONTRIBUTING" --exec cat {}
Length of output: 422269
Moving test data into the meta folder to solve the input data error does not exist during the container test.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
recipes/meta/meta.yaml (1)
Line range hint
1-77: Note regarding package visibility on Bioconda channel.The recipe changes look correct and shouldn't cause visibility issues. The visibility problem might be related to:
- Build infrastructure or deployment issues
- Package indexing delays
- Channel configuration
Please verify:
- The package build completed successfully
- The package was uploaded to Anaconda.org
- The package appears in the
biocondalabel on Anaconda.org
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
recipes/meta/conda_build_config.yaml(1 hunks)recipes/meta/meta.yaml(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- recipes/meta/conda_build_config.yaml
🔇 Additional comments (3)
recipes/meta/meta.yaml (3)
15-18: LGTM! Good improvements to build configuration.
The changes improve the recipe by:
- Using a more appropriate Windows skip condition
- Adding run_exports to handle ABI compatibility, which aligns with Bioconda best practices
59-59: LGTM! Good use of $PREFIX in test paths.
The change to use $PREFIX for accessing test data is the correct approach in conda recipes.
26-26: Verify compatibility with broader Python version range.
The Python version constraint has been broadened from >=3.9,<3.10 to >=3.8,<3.12. Please ensure that:
- The package has been tested with Python 3.8
- There are no compatibility issues with Python 3.11
Also applies to: 39-39
✅ Verification successful
Let's examine the specific Python version requirements in the relevant files.
Let's check for any Python version-specific code with proper language specification and look for setup files that might indicate version requirements.
Let's check the package's source repository and any test files to understand Python version requirements better.
Based on the gathered information, I can now provide the final response:
Python version range change appears safe to proceed
The codebase analysis shows:
- No Python version-specific features or syntax (like typing, asyncio, f-strings) are used
- Tests are basic command-line functionality checks
- No explicit version requirements in upstream dependencies
The broadened Python version range (3.8 to 3.11) should be compatible as the package appears to use basic Python features common across these versions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for Python version-specific code or imports
rg -l 'sys.version|python_version|Python 3\.'
Length of output: 965
Script:
#!/bin/bash
# Check content of files that mention Python version
rg -A 2 -B 2 'sys.version|python_version|Python 3\.' recipes/meta/
rg -A 2 -B 2 'sys.version|python_version|Python 3\.' recipes/meta/meta.yaml
# Look for any Python version-specific imports or syntax
ast-grep --pattern 'import sys' -l
ast-grep --pattern 'from __future__ import' -l
# Check for any Python version constraints in dependencies
rg 'python.*[0-9]+\.[0-9]+' recipes/meta/meta.yaml
Length of output: 592
Script:
#!/bin/bash
# Check for Python version-specific imports with proper language spec
ast-grep --lang python --pattern 'import sys'
ast-grep --lang python --pattern 'from __future__ import'
# Look for setup.py and pyproject.toml files
fd 'setup.py|pyproject.toml' recipes/meta/
# Check their content for version requirements if found
rg -A 5 'python_requires|requires-python' recipes/meta/
Length of output: 7979
Script:
#!/bin/bash
# Check package source and test files
fd -t f . recipes/meta/ -x cat {} | rg -A 5 'test|unittest|pytest'
# Look for any Python version specific features or syntax
rg -A 2 'typing\.|asyncio|f"' recipes/meta/
# Check if there are any upstream requirements specified
rg -A 5 'upstream' recipes/meta/meta.yaml
Length of output: 510
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
recipes/meta/meta.yaml (1)
Line range hint
1-83: Package visibility on Bioconda channel.The recipe configuration looks correct and shouldn't prevent package visibility. The issue might be related to:
- Build system configuration
- Package indexing
- Channel synchronization
Please try:
- Checking the build logs for any errors
- Verifying the package was successfully uploaded to Anaconda.org
- Ensuring the package index was updated
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
recipes/meta/test/files/CST_R.nii.gzis excluded by!**/*.gz
📒 Files selected for processing (1)
recipes/meta/meta.yaml(3 hunks)
🔇 Additional comments (3)
recipes/meta/meta.yaml (3)
15-18: LGTM! Build configuration properly handles ABI compatibility.
The run_exports section with max_pin="x" ensures proper version constraints are propagated to dependent packages, helping prevent ABI breakage.
55-56: Verify test file packaging and command functionality.
The test file path has changed from resources/CST_R.nii.gz to CST_R.nii.gz. Please ensure:
- The test file is properly included in the recipe
- The commands successfully generate the expected output files
Also applies to: 61-62
✅ Verification successful
Test file is properly packaged and referenced
The test file CST_R.nii.gz is correctly:
- Located at
recipes/meta/test/files/CST_R.nii.gz - Referenced in
meta.yamlunder the test files section - Used in test commands that verify core functionality (vtklevelset and cmrep_vskel)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if test file exists in the recipe directory
fd -t f "CST_R.nii.gz" recipes/meta/
# Check for any similar test files that might have been renamed
fd -t f ".nii.gz$" recipes/meta/
Length of output: 335
Script:
#!/bin/bash
# Check the meta.yaml file content to understand the file packaging
cat recipes/meta/meta.yaml
# Check if there are any test files in the test directory
ls -R recipes/meta/test/
# Check if there are any references to CST_R.nii.gz in other files
rg "CST_R.nii.gz" recipes/meta/
Length of output: 2352
26-26: Verify compatibility with broader Python version range.
The Python version constraint has been broadened from >=3.9,<3.10 to >=3.8,<3.12. Please ensure:
- The package has been tested with Python 3.8 and 3.11
- All dependencies support this version range
- No Python version-specific features are used
The numpy constraint >=1.21,<2 looks appropriate for this Python version range.
Also applies to: 39-40
✅ Verification successful
Python version range compatibility looks safe
The codebase analysis shows no usage of Python version-specific features that would be incompatible with the proposed range (>=3.8,<3.12):
- No match-case statements (Python 3.10+)
- No TypeGuard, ParamSpec, or Concatenate typing features (Python 3.10+)
- No modern collections.abc or contextlib imports
- The only "match" pattern found is in string literals, not in syntax
The broadened Python version range should work without compatibility issues.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if any Python version-specific features are used
rg -l 'match.*case|match .*:|=.*type\[|typing.TypeGuard|typing.ParamSpec|typing.Concatenate'
# Check for potential version-specific imports
rg -l 'from collections.abc import|from contextlib import AsyncExitStack|from contextlib import chdir'
Length of output: 335
Script:
#!/bin/bash
# Search for Python files to analyze version compatibility
fd -e py . recipes/meta/
# Check for Python version-specific syntax and features
rg -l '(?:match\s+.*:)|(?:\:\s*type\[)|(?:typing\.(?:TypeGuard|ParamSpec|Concatenate))|(?:from collections\.abc import)|(?:from contextlib import (?:AsyncExitStack|chdir))' --type py
# Look for setup.py or pyproject.toml for dependency information
fd -e toml -e py -g 'setup.py|pyproject.toml' recipes/meta/
# Check imports in Python files for potential version-specific dependencies
rg '^from|^import' --type py recipes/meta/
Length of output: 568
Script:
#!/bin/bash
# Search for Python files
fd -e py . recipes/meta/
# Check for Python version-specific syntax and features with simpler patterns
rg "match.*:" --type py
rg "type\[" --type py
rg "typing\.TypeGuard|typing\.ParamSpec|typing\.Concatenate" --type py
rg "from collections\.abc import" --type py
rg "from contextlib import AsyncExitStack|from contextlib import chdir" --type py
# Look for test files and run requirements
fd -g "test_*.py|*requirements*.txt" recipes/meta/
# Check imports in Python files
rg "^from|^import" --type py recipes/meta/
Length of output: 1158
|
@BiocondaBot please add label |
|
Hello, |
Python 3.12 will be supported after ITK updates its release.
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
recipes/meta/conda_build_config.yaml(1 hunks)recipes/meta/meta.yaml(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- recipes/meta/meta.yaml
🔇 Additional comments (2)
recipes/meta/conda_build_config.yaml (2)
1-3: LGTM: Appropriate UI backend selection per platform.
The platform-specific build variants are well-chosen:
- osmesa for Linux enables headless rendering
- qt for macOS provides GUI support
17-21: Verify NumPy version compatibility.
The configuration uses different NumPy versions:
- NumPy 1.22 for the first three Python versions
- NumPy 1.23 for the last version
This split version approach could potentially cause compatibility issues with other dependencies.
Let's check for NumPy version constraints in meta.yaml and other dependencies:
|
I got an error when I tried to add support to py38-py311 and exclude py3.12. "failed with error: [Errno 28] No space left on device" |
|
I have attached two screenshots of the storage before and after the test(before the test |
|
I encountered an error updating your PR branch. You can report this to bioconda/core if you'd like. |
Hello,
My package meta merged at PR #51349, and it's listed at https://bioconda.github.io/recipes/meta/README.html#package-meta. However, I can't see it on the bioconda channel. Could you please help me with this?
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>.