Skip to content
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

Update svdss to 2.0.0 #51519

Merged
merged 6 commits into from
Oct 21, 2024
Merged

Update svdss to 2.0.0 #51519

merged 6 commits into from
Oct 21, 2024

Conversation

BiocondaBot
Copy link
Collaborator

@BiocondaBot BiocondaBot commented Oct 21, 2024

Update svdss: 1.0.52.0.0

install with bioconda Conda

Info Link or Description
Recipe recipes/svdss (click to view/edit other files)
Summary Structural Variant Discovery from Sample-specific Strings.
Home https://github.com/Parsoa/SVDSS
Releases https://github.com/Parsoa/SVDSS/tags
Recipe Maintainer(s) @ldenti
Author @Parsoa

This pull request was automatically generated (see docs).

@BiocondaBot BiocondaBot added autobump Automatic Version Update new version labels Oct 21, 2024
Copy link
Contributor

coderabbitai bot commented Oct 21, 2024

📝 Walkthrough
📝 Walkthrough

Walkthrough

The pull request introduces several updates to the meta.yaml file for the svdss package. The version number is incremented from "1.0.5" to "2.0.0", and the SHA256 checksum is updated accordingly. The build number is reset from 3 to 0, and the skip directive for macOS is commented out. New entries are added under the build section, specifically run_exports, which includes a pinning directive for the svdss subpackage.

In the requirements section, several dependencies are modified: coreutils and cmake >=3.14 are removed, while libtool is added without a version constraint. Additionally, libgomp and llvm-openmp are included for both build and run requirements, specifically for Linux and macOS.

The about section sees multiple changes, including the addition of license_family, license_file, dev_url, and doc_url, while the home URL is reformatted. The summary is also updated to include a period at the end. A new DOI identifier is added to the identifiers list. The structure of the file remains consistent, with significant updates to the versioning, dependencies, and metadata.

Possibly related PRs

  • Update meta.yaml for spec2vec #49857: The changes in the meta.yaml file for the spec2vec package include updates to the version number and dependencies, similar to the updates made in the meta.yaml file for the svdss package in the main PR.
  • Update hictk to v2.0.0 #50881: The meta.yaml file for the hictk package has been updated with a new version and changes to dependencies, paralleling the updates made in the svdss package's meta.yaml.
  • Update savana to 1.2.2 #51103: The savana package's meta.yaml file has been updated with a new version and SHA256 checksum, similar to the changes made in the svdss package.
  • Update savana to 1.2.3 #51495: The savana package's meta.yaml file has been updated again with a new version and additional build requirements, reflecting the ongoing updates seen in the svdss package's meta.yaml.

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?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Outside diff range and nitpick comments (1)
recipes/svdss/build.sh (1)

1-1: Consider using /usr/bin/env in the shebang for portability

Changing the shebang to #!/bin/bash may reduce portability on systems where bash is not located at /bin/bash. Using #!/usr/bin/env bash is more portable and ensures the script uses the bash interpreter found in the user's PATH.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 32e79d5 and 74171b5.

📒 Files selected for processing (3)
  • recipes/svdss/build.sh (1 hunks)
  • recipes/svdss/build_failure.linux-64.yaml (0 hunks)
  • recipes/svdss/meta.yaml (4 hunks)
💤 Files with no reviewable changes (1)
  • recipes/svdss/build_failure.linux-64.yaml
🧰 Additional context used
🪛 Shellcheck
recipes/svdss/build.sh

[warning] 17-17: Use 'cd ... || exit' or 'cd ... || return' in case cd fails.

(SC2164)

🪛 yamllint
recipes/svdss/meta.yaml

[error] 1-1: syntax error: found character '%' that cannot start any token

(syntax)

🔇 Additional comments (5)
recipes/svdss/meta.yaml (5)

47-53: Metadata improvements look great.

The additions to the about section enhance the package metadata:

  • The license_family and license_file provide clear licensing information.
  • The updated summary is more polished with proper punctuation.
  • The dev_url and doc_url offer valuable resources for users and developers.

These changes improve the overall quality and usability of the package information.


1-1: Ignore yamllint warning for Jinja2 syntax.

The yamllint tool reports a syntax error for the '%' character, but this is a false positive. The '%' is part of the Jinja2 templating syntax, which is correct and necessary for Conda recipe YAML files.

If you want to suppress this warning in future static analysis runs, you can add a # yamllint disable-line rule:syntax comment at the end of the line. However, this is not strictly necessary as the syntax is correct for its intended use.

🧰 Tools
🪛 yamllint

[error] 1-1: syntax error: found character '%' that cannot start any token

(syntax)


29-30: Improved parallel processing support added.

The addition of libgomp for Linux and llvm-openmp for macOS suggests improved support for parallel processing on both platforms. This is a positive change that could enhance performance.

To ensure these changes have the intended effect, please run the following script to check for OpenMP usage in the source code:

#!/bin/bash
# Description: Check for OpenMP usage in the source code

# Download the source code
curl -L https://github.com/Parsoa/SVDSS/archive/refs/tags/v2.0.0.tar.gz | tar xz

# Search for OpenMP pragmas and includes
echo "OpenMP usage in source code:"
grep -R -n "#pragma omp" SVDSS-2.0.0
grep -R -n "#include <omp.h>" SVDSS-2.0.0

# Clean up
rm -rf SVDSS-2.0.0

Also applies to: 37-38


1-2: Version and checksum update looks good.

The package version has been updated from 1.0.5 to 2.0.0, which suggests significant changes. The SHA256 checksum has also been updated accordingly.

Please run the following script to verify the checksum:

🧰 Tools
🪛 yamllint

[error] 1-1: syntax error: found character '%' that cannot start any token

(syntax)


25-26: Verify build process with updated requirements.

The addition of libtool as a build requirement is appropriate. However, the removal of coreutils and cmake >=3.14 (as mentioned in the AI summary) might affect the build process.

Please run the following script to verify the build process and dependencies:

Comment on lines 13 to 16
number: 0
#skip: True # [osx]
run_exports:
- {{ pin_subpackage('svdss', max_pin="x") }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

macOS support may not be fully enabled.

  • The skip directive for macOS has been commented out.
  • macOS-specific dependencies like llvm-openmp are still present in meta.yaml (lines 30 and 38).
  • No macOS-specific build script (build-osx.sh) found.

Please review and ensure that all macOS support configurations are correctly implemented.

🔗 Analysis chain

Build section changes look good, but verify macOS support.

The build number has been correctly reset to 0 for the new version. The addition of the run_exports section is a good practice for ensuring correct version pinning.

The macOS skip directive has been commented out. Please confirm that the package now supports macOS by running the following script:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for macOS-specific build instructions or dependencies

# Search for macOS-specific conditionals in the meta.yaml file
echo "macOS-specific conditionals in meta.yaml:"
grep -n '\[osx\]' recipes/svdss/meta.yaml

# Check if there's a separate macOS build script
if [ -f recipes/svdss/build-osx.sh ]; then
    echo "macOS-specific build script found: recipes/svdss/build-osx.sh"
else
    echo "No macOS-specific build script found."
fi

# Check for macOS-specific dependencies
echo "macOS-specific dependencies:"
grep -n '# \[osx\]' recipes/svdss/meta.yaml

Length of output: 864


Script:

#!/bin/bash
# Description: Verify macOS support by checking for conditionals and build scripts in meta.yaml

# Search for macOS-specific conditionals in meta.yaml
echo "Checking for macOS-specific conditionals in meta.yaml:"
grep -n '\[osx\]' recipes/svdss/meta.yaml || echo "No macOS-specific conditionals found."

# Check for the presence of a macOS-specific build script
echo "Checking for macOS-specific build script:"
if [ -f recipes/svdss/build-osx.sh ]; then
    echo "macOS-specific build script found: recipes/svdss/build-osx.sh"
else
    echo "No macOS-specific build script found."
fi

# Search for macOS-specific dependencies in meta.yaml
echo "Checking for macOS-specific dependencies in meta.yaml:"
grep -n '# \[osx\]' recipes/svdss/meta.yaml || echo "No macOS-specific dependencies found."

Length of output: 717


extra:
identifiers:
- biotools:svdss
- doi:10.1038/s41592-022-01674-1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

DOI does not resolve correctly

The DOI 10.1038/s41592-022-01674-1 does not resolve. Please verify and correct the DOI in recipes/svdss/meta.yaml.

🔗 Analysis chain

DOI addition is excellent.

The inclusion of a DOI (Digital Object Identifier) is a valuable addition for academic citation and tracking of the software.

Please run the following script to verify the DOI:


The previous script did not verify the DOI as intended. Please run the following script to verify the DOI:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the DOI

# Extract the DOI
doi=$(grep -oP 'doi:\K[^\s]+' recipes/svdss/meta.yaml)

# Check if the DOI resolves
if curl -s -o /dev/null -w "%{http_code}" "https://doi.org/$doi" | grep -q "200"; then
    echo "DOI $doi is valid and resolves correctly."
else
    echo "Error: DOI $doi does not resolve. Please check the DOI."
fi

Length of output: 2219


Script:

#!/bin/bash
# Description: Verify the DOI

# Extract the DOI
doi=$(grep -oP 'doi:\K[^\s]+' recipes/svdss/meta.yaml)

# Check if the DOI resolves
if curl -s -o /dev/null -w "%{http_code}" "https://doi.org/$doi" | grep -q "200"; then
    echo "DOI $doi is valid and resolves correctly."
else
    echo "Error: DOI $doi does not resolve. Please check the DOI."
fi

Length of output: 346

"${CONFIG_ARGS}"
cmake --build build -j "${CPU_COUNT}" -v

cd build
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Handle potential failure when changing directories

It's recommended to handle cases where cd build might fail. You can modify the command to cd build || exit to ensure the script exits if the directory change is unsuccessful.

This addresses the Shellcheck warning:

[warning] 17-17: Use 'cd ... || exit' or 'cd ... || return' in case cd fails. (SC2164)

🧰 Tools
🪛 Shellcheck

[warning] 17-17: Use 'cd ... || exit' or 'cd ... || return' in case cd fails.

(SC2164)

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (1)
recipes/svdss/build.sh (1)

4-8: LGTM with a minor suggestion: Environment variable setup

The addition of environment variables for include paths, library paths, and compiler flags is a good practice. It ensures that the build process uses the correct paths and optimization levels.

However, there's a minor redundancy in the CFLAGS and CXXFLAGS settings:

Consider removing the redundant -L${PREFIX}/lib from CFLAGS, as it's already included in LDFLAGS:

-export CFLAGS="${CFLAGS} -O3 -L${PREFIX}/lib"
+export CFLAGS="${CFLAGS} -O3"

This change would maintain the same functionality while reducing redundancy.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 74171b5 and b1cecfd.

📒 Files selected for processing (1)
  • recipes/svdss/build.sh (1 hunks)
🧰 Additional context used
🪛 Shellcheck
recipes/svdss/build.sh

[warning] 23-23: Use 'cd ... || exit' or 'cd ... || return' in case cd fails.

(SC2164)

🔇 Additional comments (3)
recipes/svdss/build.sh (3)

1-3: LGTM: Improved shebang and directory creation

The changes to the shebang and the addition of the directory creation step are good improvements. The more specific shebang ensures compatibility, and creating the directory beforehand prevents potential installation issues.


10-14: LGTM: Improved cross-platform compatibility

The addition of OS-specific configuration is a great improvement. Setting CMAKE_FIND_FRAMEWORK=NEVER and CMAKE_FIND_APPBUNDLE=NEVER for macOS helps avoid potential conflicts with system frameworks during the build process. This change enhances the script's portability and reliability across different platforms.


16-21: LGTM: Improved CMake configuration and build process

The updates to the CMake configuration and build commands are excellent improvements:

  1. Use of modern CMake syntax with -S and -B options improves clarity.
  2. Explicit setting of build type, compilers, and flags ensures consistency across different environments.
  3. The use of parallel jobs (-j "${CPU_COUNT}") can significantly speed up the build process.
  4. Verbose output (-v) is helpful for debugging potential build issues.

These changes contribute to a more robust and efficient build process.

Comment on lines 23 to 25
cd build
chmod 0755 SVDSS
cp -f SVDSS ${PREFIX}/bin
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

LGTM with a suggestion: Final build steps and installation

The final steps for setting permissions and installing the executable are correct. However, there's a minor improvement we can make:

To handle potential failure when changing directories, modify the cd command as follows:

-cd build
+cd build || exit 1

This change ensures that the script will exit if the directory change fails, preventing any subsequent commands from running in an unexpected directory.

The rest of the installation process looks good, with proper permissions set and the executable correctly copied to the installation directory.

📝 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.

Suggested change
cd build
chmod 0755 SVDSS
cp -f SVDSS ${PREFIX}/bin
cd build || exit 1
chmod 0755 SVDSS
cp -f SVDSS ${PREFIX}/bin
🧰 Tools
🪛 Shellcheck

[warning] 23-23: Use 'cd ... || exit' or 'cd ... || return' in case cd fails.

(SC2164)

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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 (1)
recipes/svdss/build.sh (1)

1-3: Consider reverting shebang for improved portability

The shebang has been changed from #!/usr/bin/env bash to #!/bin/bash. While this works in most cases, using env is generally more portable as it allows the system to locate the correct bash interpreter, especially in non-standard environments.

The directory creation for ${PREFIX}/bin is a good practice to ensure the installation directory exists.

Consider reverting the shebang:

-#!/bin/bash
+#!/usr/bin/env bash
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between b1cecfd and 3dd7acb.

📒 Files selected for processing (1)
  • recipes/svdss/build.sh (1 hunks)
🧰 Additional context used
🔇 Additional comments (4)
recipes/svdss/build.sh (4)

4-8: LGTM: Environment variables setup

The environment variables are set up correctly, including paths for includes and libraries. The use of optimization flags (-O3) is appropriate for a release build. Good practice in maintaining consistency with the conda build environment by appending to existing flags.


10-14: LGTM: OS-specific configuration

The conditional setup for macOS-specific CMake arguments is well-implemented. Disabling framework and app bundle finding on macOS can prevent issues with system-installed libraries interfering with conda-installed ones. The use of an empty string for non-macOS systems is a clean approach.


16-21: LGTM: CMake configuration and build

The CMake configuration and build commands are well-structured:

  • Modern CMake syntax with -S and -B options.
  • Proper setting of flags and compilers.
  • Use of parallel jobs (CPU_COUNT) for improved build performance.
  • Verbose output (-v) which is helpful for debugging.

These changes should result in a more efficient and transparent build process.


23-24: LGTM: Final installation steps

The final installation steps are correct and address previous concerns:

  • Proper permissions (0755) are set for the executable.
  • The executable is copied to the correct location (${PREFIX}/bin).
  • Previous concerns about potential directory change failures have been addressed by removing the cd command.

These changes result in a more robust installation process.

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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 (2)
recipes/svdss/build.sh (2)

4-8: LGTM with a suggestion: Environment variable exports

The environment variable exports look good and will ensure the build process has the correct paths and flags. The addition of optimization flags is appropriate for a release build.

Consider adding quotes around the variable expansions to handle potential spaces in paths:

-export INCLUDE_PATH="${PREFIX}/include"
-export LIBRARY_PATH="${PREFIX}/lib"
-export LDFLAGS="${LDFLAGS} -L${PREFIX}/lib"
-export CFLAGS="${CFLAGS} -O3 -L${PREFIX}/lib"
-export CXXFLAGS="${CXXFLAGS} -O3 -I${PREFIX}/include"
+export INCLUDE_PATH="${PREFIX}/include"
+export LIBRARY_PATH="${PREFIX}/lib"
+export LDFLAGS="${LDFLAGS} -L\"${PREFIX}/lib\""
+export CFLAGS="${CFLAGS} -O3 -L\"${PREFIX}/lib\""
+export CXXFLAGS="${CXXFLAGS} -O3 -I\"${PREFIX}/include\""

16-21: LGTM with a suggestion: CMake configuration and build

The CMake configuration and build commands are well-structured and make good use of the exported environment variables. The use of parallel jobs and verbose output is excellent for efficiency and debugging.

Consider adding error checking to the CMake commands:

-cmake -S. -B build -DCMAKE_BUILD_TYPE=Release \
+cmake -S. -B build -DCMAKE_BUILD_TYPE=Release \
 	-DCONDAPREFIX="${PREFIX}" -DCMAKE_CXX_COMPILER="${CXX}" \
 	-DCMAKE_CXX_FLAGS="${CXXFLAGS}" -DCMAKE_C_COMPILER="${CC}" \
 	-DCMAKE_C_FLAGS="${CFLAGS}" \
-	"${CONFIG_ARGS}"
-cmake --build build -j "${CPU_COUNT}" -v
+	"${CONFIG_ARGS}" || exit 1
+cmake --build build -j "${CPU_COUNT}" -v || exit 1

This ensures the script exits if either the CMake configuration or build step fails.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 3dd7acb and 9a9837a.

📒 Files selected for processing (1)
  • recipes/svdss/build.sh (1 hunks)
🧰 Additional context used
🔇 Additional comments (3)
recipes/svdss/build.sh (3)

1-3: LGTM: Appropriate shebang and directory creation

The updated shebang and directory creation look good. Using /bin/bash is more specific and creating the installation directory is a good practice.


10-14: LGTM: Appropriate OS-specific configuration

The conditional check for macOS and the corresponding CMake arguments are well-implemented. This addresses potential issues specific to macOS builds while providing a sensible default for other operating systems.


23-24: LGTM: Correct permissions and installation

The final steps for setting permissions and installing the executable are correct. The permissions (0755) are appropriate for an executable, and the installation location (${PREFIX}/bin) is correct for conda packages.

Note: The previous concerns about changing directories (cd) are no longer applicable as the new build process doesn't use cd commands.

@mencian mencian merged commit 44de0dc into master Oct 21, 2024
7 checks passed
@mencian mencian deleted the bump/svdss branch October 21, 2024 10:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
autobump Automatic Version Update new version
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants