Rebuild vcflib #52221
Rebuild vcflib #52221
Conversation
📝 WalkthroughWalkthroughThe pull request introduces several changes primarily 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: 1
🧹 Outside diff range and nitpick comments (2)
recipes/vcflib/pc.patch (1)
1-21: Build system improvements look goodThe changes improve both the build optimization and library integration capabilities. The modifications follow CMake best practices and are well-structured.
Consider documenting the pkg-config integration in the package documentation to help downstream consumers.
recipes/vcflib/build.sh (1)
WFA2 library dependency needs to be added to host section
The verification revealed that:
- WFA2 library is listed as a build dependency but missing from the host section
- The CMake configuration expects WFA2 library and includes to be available
- The patch file (0006-wfa2-lib.patch) enforces WFA2 as a required dependency
Required changes in meta.yaml:
- Add
wfa2-libto the host section under requirements🔗 Analysis chain
Line range hint
19-22: Verify WFA2 library linkageThe script links against WFA2 library (-lwfa2) and disables git submodule (WFA_GITMODULE=OFF). Please ensure the WFA2 library is properly declared as a dependency in meta.yaml.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if WFA2 is declared as a dependency rg -A 5 "wfa2" recipes/vcflib/meta.yaml # Check if the library is available in the conda environment if [ -f "${PREFIX}/lib/libwfa2.so" ] || [ -f "${PREFIX}/lib/libwfa2.dylib" ]; then echo "WFA2 library found" else echo "WARNING: WFA2 library not found in PREFIX" fiLength of output: 722
Script:
#!/bin/bash # Let's verify if wfa2-lib is properly declared in both build and host sections rg -A 10 "^requirements:" recipes/vcflib/meta.yaml # Check if there are any patches related to wfa2 fd "wfa2.*patch" recipes/vcflib/ # Check the content of the wfa2 patch to understand the modifications if [ -f "recipes/vcflib/0006-wfa2-lib.patch" ]; then cat recipes/vcflib/0006-wfa2-lib.patch fiLength of output: 1805
🧰 Tools
🪛 Shellcheck
[warning] 10-10: Quote this to prevent word splitting.
(SC2046)
[warning] 11-11: Declare and assign separately to avoid masking return values.
(SC2155)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
recipes/vcflib/build.sh(1 hunks)recipes/vcflib/meta.yaml(2 hunks)recipes/vcflib/pc.patch(1 hunks)recipes/vcflib/vcflib.pc.in(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- recipes/vcflib/vcflib.pc.in
🔇 Additional comments (6)
recipes/vcflib/pc.patch (2)
18-19: Verify pkg-config template file contents
The addition of pkg-config support is a good practice for library distribution. However, we should ensure the template file contains the correct variables.
Run the following script to check the template file:
✅ Verification successful
pkg-config template file looks correct and complete
The vcflib.pc.in template contains all the necessary variables and follows standard pkg-config conventions:
- Correct path variables: prefix, exec_prefix, libdir, includedir
- Package metadata: Name, Version, Description
- Proper linking flags: Libs and Cflags with correct paths
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the pkg-config template file
# Check if the template file exists in the recipe
if [ -f recipes/vcflib/vcflib.pc.in ]; then
echo "Template content:"
cat recipes/vcflib/vcflib.pc.in
else
echo "Warning: vcflib.pc.in not found in recipe directory"
# Search for the template file in the repository
fd -g "vcflib.pc.in"
fi
# Check for common pkg-config variables that should be defined
rg -l "@(prefix|libdir|includedir|VERSION)" recipes/vcflib/
Length of output: 506
9-10: Verify the impact of increased optimization level
Changing from -O2 to -O3 optimization level could improve performance but might need validation for stability and correctness.
Run the following script to check if there are any known issues with -O3 in the project:
recipes/vcflib/build.sh (2)
Line range hint 34-41: Platform-specific build configuration looks good
The MacOS-specific modifications properly handle:
- Runtime library path with rpath
- Modern C++17 standard with libc++
- Framework and bundle search settings
🧰 Tools
🪛 Shellcheck
[warning] 10-10: Quote this to prevent word splitting.
(SC2046)
[warning] 11-11: Declare and assign separately to avoid masking return values.
(SC2155)
Line range hint 43-55: CMake build configuration is well structured
The build configuration properly handles:
- Shared library building
- Installation paths
- Compiler flags propagation
- Parallel build support
🧰 Tools
🪛 Shellcheck
[warning] 10-10: Quote this to prevent word splitting.
(SC2046)
[warning] 11-11: Declare and assign separately to avoid masking return values.
(SC2155)
recipes/vcflib/meta.yaml (2)
35-35: LGTM: Build number increment is appropriate.
The build number increment from 1 to 2 is correct as it reflects the changes in the build configuration with the addition of the new patch file.
20-20: Verify the existence of pc.patch file.
The addition of pc.patch follows the existing pattern of patch files. This patch enhances the package by adding pkg-config support for better library integration.
✅ Verification successful
The pc.patch file exists and contains valid changes
The patch file exists at recipes/vcflib/pc.patch and contains legitimate changes:
- Optimizes compilation flags from
-O2to-O3 - Adds pkg-config support by configuring and installing
.pcfiles
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the existence and content of pc.patch file
# Expected: pc.patch file exists in the recipe directory
# Check if pc.patch exists
fd -t f "pc.patch" recipes/vcflib/
# Display patch content if found
if [ $? -eq 0 ]; then
echo "Patch content:"
cat recipes/vcflib/pc.patch
fi
Length of output: 979
recipes/vcflib/build.sh
Outdated
| @@ -4,6 +4,8 @@ set -ex | |||
| OS=$(uname) | |||
| ARCH=$(uname -m) | |||
|
|
|||
| cp -rf ${RECIPE_DIR}/vcflib.pc.in ${SRC_DIR}/ | |||
There was a problem hiding this comment.
💡 Codebase verification
The -rf flags are unnecessary for copying a single template file
The template file exists and is a standard pkg-config configuration file. Since we're copying a single regular file, the recursive (-r) and force (-f) flags are not needed and can be safely removed.
-cp -rf ${RECIPE_DIR}/vcflib.pc.in ${SRC_DIR}/
+cp ${RECIPE_DIR}/vcflib.pc.in ${SRC_DIR}/🔗 Analysis chain
Verify pkg-config template file and optimize copy command
The -rf flags are unnecessary for copying a single file. Also, we should verify the existence of the template file.
Consider simplifying the copy command:
-cp -rf ${RECIPE_DIR}/vcflib.pc.in ${SRC_DIR}/
+cp ${RECIPE_DIR}/vcflib.pc.in ${SRC_DIR}/🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify the existence of vcflib.pc.in template
if [ -f "recipes/vcflib/vcflib.pc.in" ]; then
echo "Template file exists"
cat recipes/vcflib/vcflib.pc.in
else
echo "ERROR: Template file missing"
fi
Length of output: 450
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (7)
recipes/vcflib/0001-CMakeLists.patch(1 hunks)recipes/vcflib/0006-wfa2-lib.patch(0 hunks)recipes/vcflib/backport_pr_394.patch(0 hunks)recipes/vcflib/march_native.patch(0 hunks)recipes/vcflib/meta.yaml(2 hunks)recipes/vcflib/pkg-config.patch(0 hunks)recipes/vcflib/shared_lib.patch(0 hunks)
💤 Files with no reviewable changes (5)
- recipes/vcflib/0006-wfa2-lib.patch
- recipes/vcflib/backport_pr_394.patch
- recipes/vcflib/march_native.patch
- recipes/vcflib/pkg-config.patch
- recipes/vcflib/shared_lib.patch
🚧 Files skipped from review as they are similar to previous changes (1)
- recipes/vcflib/meta.yaml
🔇 Additional comments (5)
recipes/vcflib/0001-CMakeLists.patch (5)
26-36: Verify the inversion of logic for HTSLIB_FOUND and TABIXPP_FOUND checks
The conditions for checking HTSLIB_FOUND and TABIXPP_FOUND have been inverted (lines 27~, 39~). Previously, the code checked for NOT HTSLIB_FOUND and NOT TABIX_FOUND, but now it checks for HTSLIB_FOUND and TABIXPP_FOUND. Ensure that this inversion correctly reflects the intended build behavior and that the included libraries are used appropriately when the external ones are not found.
Confirm that the logic change does not unintentionally skip building the included htslib and tabixpp when the external libraries are absent.
65-68: Consider the implications of changing vcflib from STATIC to SHARED library
Changing vcflib from a STATIC library to a SHARED library (line 65~) can affect how downstream projects link against it. Shared libraries are linked at runtime, which could introduce dependencies on the library being present in the system's library path.
Ensure that this change is intentional and that package distribution methods (e.g., conda recipes) are updated to handle the shared library appropriately. Verify that consumers of vcflib are compatible with this change.
91-92: Review the optimization level change for htslib
The optimization flag for building htslib has been changed from -O2 to -O3 (line 92~). While -O3 enables more aggressive optimizations that might improve performance, it can sometimes lead to larger binaries or unexpected behavior.
Consider testing the htslib build with -O3 to ensure stability and performance benefits. If no significant gains are observed, it might be safer to retain -O2.
120-125: Ensure all executables are linked with WFALIB where necessary
Additional target_link_libraries entries have been added to link various executables with WFALIB (lines 124~, 127~ to 139~). This is essential for executables that depend on WFA functionalities.
Verify that all executables requiring WFALIB are correctly linked and that there are no missing target_link_libraries statements for any WFA-dependent executables.
Also applies to: 127-139
52-55: Include vcfwfa_SOURCE in all relevant executable targets
The source files vcfwfa_SOURCE have been added (lines 52~ to 55~) and included in the executable definitions for certain binaries (lines 121~ to 122~). Ensure that all executables that depend on the WFA features include these source files in their build definitions.
Double-check if any additional executables should include vcfwfa_SOURCE to prevent linkage or runtime errors.
Also applies to: 121-122
recipes/vcflib/0001-CMakeLists.patch
Outdated
| -install(FILES ${INCLUDES} DESTINATION include) | ||
| +install(FILES ${INCLUDES} DESTINATION include/vcflib) | ||
| +configure_file(${CMAKE_CURRENT_SOURCE_DIR}/vcflib.pc.in ${CMAKE_CURRENT_BINARY_DIR}/vcflib.pc @ONLY) | ||
| +install(FILES ${CMAKE_CURRENT_BINARY_DIR}/vcflib.pc DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Update header installation path requires downstream adjustments
The installation path for headers has changed from include to include/vcflib (line 147~). Projects that include vcflib headers will need to update their include paths to reflect this new directory structure.
Consider providing a note in the documentation or release notes to inform users of this change. Alternatively, you could install headers to both locations to maintain backward compatibility.
recipes/vcflib/0001-CMakeLists.patch
Outdated
| -if (${CMAKE_BUILD_TYPE} MATCHES Release) | ||
| - set(EXTRA_FLAGS "-march=native -D_FILE_OFFSET_BITS=64") | ||
| - # set(CMAKE_CXX_FLAGS_RELEASE "-DNDEBUG") # reset CXX_FLAGS to replace -O3 with -Ofast | ||
| -endif() | ||
| - | ||
| if ((${CMAKE_BUILD_TYPE} MATCHES Release) OR (${CMAKE_BUILD_TYPE} MATCHES RelWithDebInfo)) | ||
| - set (CMAKE_C_FLAGS "${OpenMP_C_FLAGS} ${EXTRA_FLAGS}") | ||
| - set (CMAKE_CXX_FLAGS "${OpenMP_CXX_FLAGS} ${EXTRA_FLAGS}") | ||
| + set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${EXTRA_FLAGS}") | ||
| + set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${EXTRA_FLAGS}") | ||
| endif () |
There was a problem hiding this comment.
Critical Issue: EXTRA_FLAGS may be undefined and cause build errors
The EXTRA_FLAGS variable is appended to CMAKE_C_FLAGS and CMAKE_CXX_FLAGS in lines 17~ and 18~, but its definition has been removed in the changes (lines 9~ to 13~). This could result in EXTRA_FLAGS being undefined, potentially causing build errors due to empty or unintended compiler flags.
Consider defining EXTRA_FLAGS before appending it, or remove it from the append statements if it's no longer needed. For example:
+set(EXTRA_FLAGS "-march=native -D_FILE_OFFSET_BITS=64")
set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${EXTRA_FLAGS}")
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${EXTRA_FLAGS}")Committable suggestion skipped: line range outside the PR's diff.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
recipes/vcflib/0002-CMakeLists.patch(1 hunks)recipes/vcflib/build.sh(1 hunks)recipes/vcflib/meta.yaml(2 hunks)
🧰 Additional context used
🪛 Shellcheck
recipes/vcflib/build.sh
[warning] 10-10: Quote this to prevent word splitting.
(SC2046)
[warning] 11-11: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 13-13: Quote this to prevent word splitting.
(SC2046)
[warning] 14-14: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 16-16: Quote this to prevent word splitting.
(SC2046)
[warning] 17-17: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 19-19: Quote this to prevent word splitting.
(SC2046)
[warning] 20-20: Declare and assign separately to avoid masking return values.
(SC2155)
🔇 Additional comments (11)
recipes/vcflib/build.sh (2)
7-7: The -rf flags are unnecessary for copying a single template file
Line range hint 1-58: Verify builds across all supported architectures
Since this PR rebuilds vcflib with expanded architecture support and updated Zig compiler version, please ensure that:
- The package builds successfully on all supported architectures (x86_64, aarch64)
- The pkg-config integration works correctly after installation
- The shared library is properly linked with all dependencies
🧰 Tools
🪛 Shellcheck
[warning] 10-10: Quote this to prevent word splitting.
(SC2046)
[warning] 11-11: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 13-13: Quote this to prevent word splitting.
(SC2046)
[warning] 14-14: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 16-16: Quote this to prevent word splitting.
(SC2046)
[warning] 17-17: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 19-19: Quote this to prevent word splitting.
(SC2046)
[warning] 20-20: Declare and assign separately to avoid masking return values.
(SC2155)
recipes/vcflib/meta.yaml (4)
14-16: Verify the consolidated patches maintain all previous functionality
The new patches (0001-vcflib.patch and 0002-CMakeLists.patch) appear to replace several previous patches (pkg-config.patch, shared_lib.patch, backport_pr_394.patch, march_native.patch). Please ensure that all functionality from the removed patches is properly maintained in the new consolidated patches.
17-28: Verify compatibility with Zig 0.13.0
The Zig compiler version has been updated from 0.10.1 to 0.13.0, which is a significant version jump. Please ensure:
- The build system is compatible with the new Zig version
- All platform-specific builds (x86_64, aarch64) have been tested
- No breaking changes affect the build process
31-31: Build number increment looks good
The build number increment is appropriate for this package rebuild.
89-89: Verify osx-arm64 build stability
The addition of osx-arm64 support is noted, but there's a comment indicating a previous Zig error with dyld_stub_binder. Please verify:
- This issue has been resolved with Zig 0.13.0
- The package builds and functions correctly on osx-arm64
recipes/vcflib/0002-CMakeLists.patch (5)
9-12: Verify the impact of removing optimization flags
The removal of the EXTRA_FLAGS setting for Release builds eliminates the -march=native and -D_FILE_OFFSET_BITS=64 flags. This may affect the performance optimization and file handling on certain architectures. Please verify if these flags are no longer necessary or if alternatives should be introduced.
21-29: Changing vcflib from static to shared library
The add_library command changes vcflib from a static (STATIC) to a shared (SHARED) library. This alteration affects how the library is linked and distributed. Ensure that all dependent projects are compatible with a shared library. Additionally, by linking tabixpp publicly, you're exposing it to consumers of vcflib. Confirm that this is the intended behavior and that tabixpp is correctly installed or packaged alongside vcflib.
37-40: Properly setting shared library versioning
Setting the SOVERSION property for vcflib ensures correct versioning and ABI compatibility for the shared library. This is a best practice for shared libraries to manage upgrades and dependencies effectively.
48-48: Ensure removal of WFALIB installation is intentional
The installation command for ${WFALIB} has been removed. If WFALIB is still a required component, omitting its installation may lead to build or runtime issues. Please verify that WFALIB is either no longer needed or is handled elsewhere in the build process.
51-52: Add vcflib.pc for pkg-config support
Including the vcflib.pc file enhances the integration with other projects by allowing pkg-config to locate and use vcflib easily. This improves the usability and maintainability of the library.
| echo $(pwd)/zig-macos-x86_64-* | ||
| export PATH="$(pwd)/zig-macos-x86_64-0.10.1:${PATH}" | ||
| export PATH="$(pwd)/zig-macos-x86_64-0.13.0:${PATH}" | ||
| elif [[ "${OS}" == "Darwin" && "${ARCH}" == "arm64" ]]; then | ||
| echo $(pwd)/zig-macos-aarch64-* | ||
| export PATH="$(pwd)/zig-macos-aarch64-0.10.1:${PATH}" | ||
| export PATH="$(pwd)/zig-macos-aarch64-0.13.0:${PATH}" | ||
| elif [[ "${OS}" == "Linux" && "${ARCH}" == "aarch64" ]]; then | ||
| echo $(pwd)/zig-linux-${ARCH}-* | ||
| export PATH="$(pwd)/zig-linux-${ARCH}-0.13.0:${PATH}" | ||
| else | ||
| echo $(pwd)/zig-linux-${ARCH}-* | ||
| export PATH="$(pwd)/zig-linux-${ARCH}-0.10.1:${PATH}" | ||
| export PATH="$(pwd)/zig-linux-${ARCH}-0.13.0:${PATH}" | ||
| fi |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Improve robustness of PATH setting logic
The current implementation has potential reliability issues:
- Unquoted command substitution could break with paths containing spaces
- Direct export assignments mask potential errors in PATH setting
Consider this more robust implementation:
if [[ "${OS}" == "Darwin" && "${ARCH}" == "x86_64" ]]; then
- echo $(pwd)/zig-macos-x86_64-*
- export PATH="$(pwd)/zig-macos-x86_64-0.13.0:${PATH}"
+ zig_path="$(pwd)/zig-macos-x86_64-0.13.0"
elif [[ "${OS}" == "Darwin" && "${ARCH}" == "arm64" ]]; then
- echo $(pwd)/zig-macos-aarch64-*
- export PATH="$(pwd)/zig-macos-aarch64-0.13.0:${PATH}"
+ zig_path="$(pwd)/zig-macos-aarch64-0.13.0"
elif [[ "${OS}" == "Linux" && "${ARCH}" == "aarch64" ]]; then
- echo $(pwd)/zig-linux-${ARCH}-*
- export PATH="$(pwd)/zig-linux-${ARCH}-0.13.0:${PATH}"
+ zig_path="$(pwd)/zig-linux-${ARCH}-0.13.0"
else
- echo $(pwd)/zig-linux-${ARCH}-*
- export PATH="$(pwd)/zig-linux-${ARCH}-0.13.0:${PATH}"
+ zig_path="$(pwd)/zig-linux-${ARCH}-0.13.0"
fi
+
+if [[ ! -d "${zig_path}" ]]; then
+ echo "Error: Zig directory not found: ${zig_path}"
+ exit 1
+fi
+
+export PATH="${zig_path}:${PATH}"This implementation:
- Properly quotes all path variables
- Separates path resolution from export
- Adds validation to ensure the Zig directory exists
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| echo $(pwd)/zig-macos-x86_64-* | |
| export PATH="$(pwd)/zig-macos-x86_64-0.10.1:${PATH}" | |
| export PATH="$(pwd)/zig-macos-x86_64-0.13.0:${PATH}" | |
| elif [[ "${OS}" == "Darwin" && "${ARCH}" == "arm64" ]]; then | |
| echo $(pwd)/zig-macos-aarch64-* | |
| export PATH="$(pwd)/zig-macos-aarch64-0.10.1:${PATH}" | |
| export PATH="$(pwd)/zig-macos-aarch64-0.13.0:${PATH}" | |
| elif [[ "${OS}" == "Linux" && "${ARCH}" == "aarch64" ]]; then | |
| echo $(pwd)/zig-linux-${ARCH}-* | |
| export PATH="$(pwd)/zig-linux-${ARCH}-0.13.0:${PATH}" | |
| else | |
| echo $(pwd)/zig-linux-${ARCH}-* | |
| export PATH="$(pwd)/zig-linux-${ARCH}-0.10.1:${PATH}" | |
| export PATH="$(pwd)/zig-linux-${ARCH}-0.13.0:${PATH}" | |
| fi | |
| if [[ "${OS}" == "Darwin" && "${ARCH}" == "x86_64" ]]; then | |
| zig_path="$(pwd)/zig-macos-x86_64-0.13.0" | |
| elif [[ "${OS}" == "Darwin" && "${ARCH}" == "arm64" ]]; then | |
| zig_path="$(pwd)/zig-macos-aarch64-0.13.0" | |
| elif [[ "${OS}" == "Linux" && "${ARCH}" == "aarch64" ]]; then | |
| zig_path="$(pwd)/zig-linux-${ARCH}-0.13.0" | |
| else | |
| zig_path="$(pwd)/zig-linux-${ARCH}-0.13.0" | |
| fi | |
| if [[ ! -d "${zig_path}" ]]; then | |
| echo "Error: Zig directory not found: ${zig_path}" | |
| exit 1 | |
| fi | |
| export PATH="${zig_path}:${PATH}" |
🧰 Tools
🪛 Shellcheck
[warning] 10-10: Quote this to prevent word splitting.
(SC2046)
[warning] 11-11: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 13-13: Quote this to prevent word splitting.
(SC2046)
[warning] 14-14: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 16-16: Quote this to prevent word splitting.
(SC2046)
[warning] 17-17: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 19-19: Quote this to prevent word splitting.
(SC2046)
[warning] 20-20: Declare and assign separately to avoid masking return values.
(SC2155)
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>.