chore(migration): Migrate code from googleapis/python-bigtable into packages/google-cloud-bigtable

[parthea]

See #10992.

This PR should be merged with a merge-commit, not a squash-commit, in order to preserve the git history.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request focuses on migrating the Bigtable code from the googleapis/python-bigtable repository to the packages/google-cloud-bigtable directory. It also introduces CrossSync, a mechanism for sharing logic between async and sync code, along with associated tooling and configurations. The PR aims to maintain git history and improve code maintainability.

Highlights

• Code Migration: Migrated code from the googleapis/python-bigtable repository into the packages/google-cloud-bigtable directory, as per issue Adopt split repo: _python-bigtable_ #10992.
• Cross-Sync Implementation: Introduced CrossSync to facilitate sharing logic between asynchronous and synchronous code, including shims, annotations, and code generation.
• File Additions: Added several new files to support CrossSync, code generation, and configuration, including .coveragerc, .cross_sync/README.md, .cross_sync/generate.py, .cross_sync/transformers.py, .flake8, .gitignore, .gitmodules, and .librarian/generator-input/.repo-metadata.json.
• Merge Strategy: Specified that this PR should be merged with a merge-commit, not a squash-commit, to preserve the git history.

Activity

• Initial implementation of code migration and CrossSync setup.
• Addition of necessary configuration and support files.
• Specification of merge strategy to preserve git history.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request migrates a large number of files for the google-cloud-bigtable package. The changes primarily consist of adding new files, including source code, documentation, and configuration. My review focuses on ensuring the correctness, maintainability, and security of the newly added code. I've identified a few areas for improvement, such as unsafe command-line argument handling, potential security risks with eval, and opportunities to improve code clarity and robustness.

_{Note: Security Review is unavailable for this PR.}

I am having trouble creating individual review comments. Click here to see my feedback.

packages/google-cloud-bigtable/.cross_sync/generate.py (104)

Accessing sys.argv[1] directly is unsafe and will raise an IndexError if the script is run without command-line arguments. It's better to validate the number of arguments first and provide a helpful usage message if an argument is missing.

    if len(sys.argv) < 2:
        raise SystemExit(f"Usage: {sys.argv[0]} <path>")
    search_root = sys.argv[1]

packages/google-cloud-bigtable/.cross_sync/README.md (40)

There appears to be a typo in the method name. It should likely be CrossSync.event_wait() instead of CrossSync,event_wait().

- `CrossSync.event_wait()`

packages/google-cloud-bigtable/.cross_sync/generate.py (26)

For better code clarity and maintainability, please add a type hint for the file_path parameter. Based on its usage, str would be appropriate.

def extract_header_comments(file_path: str) -> str:

packages/google-cloud-bigtable/.cross_sync/generate.py (32)

It is a best practice to explicitly specify the file encoding when using open(). This prevents potential issues on different platforms where the default encoding might vary. Please consider adding encoding="utf-8".

    with open(file_path, "r", encoding="utf-8") as f:

packages/google-cloud-bigtable/.cross_sync/generate.py (85)

It is a best practice to explicitly specify the file encoding when using open(). This prevents potential issues on different platforms where the default encoding might vary. Please consider adding encoding="utf-8".

        ast_tree = ast.parse(open(file_path, encoding="utf-8").read())

packages/google-cloud-bigtable/.cross_sync/transformers.py (34)

Modifying sys.path at runtime is generally discouraged as it can make the code harder to understand and maintain, and may lead to module import conflicts. Consider using relative imports or restructuring the project to avoid this.

packages/google-cloud-bigtable/.cross_sync/transformers.py (245)

Comparing a boolean value with == True is not idiomatic in Python. It's clearer and more conventional to use the value directly in a boolean context, or use is True for a strict identity check.

            return self._is_async_check(node.left) and (isinstance(node.ops[0], ast.Eq) or isinstance(node.ops[0], ast.Is)) and len(node.comparators) == 1 and isinstance(node.comparators[0], ast.Constant) and node.comparators[0].value is True

packages/google-cloud-bigtable/.kokoro/conformance.sh (38)

The use of eval with a variable can be a security risk if the content of $TEST_ARGS is not strictly controlled, as it could allow for arbitrary command execution. While this might be safe in a controlled CI environment, it's a good practice to avoid eval whenever possible. Consider alternative ways to pass arguments that do not require evaluation.

packages/google-cloud-bigtable/.kokoro/populate-secrets.sh (28)

The for key in $(...) construct is not robust against values in ${SECRET_MANAGER_KEYS} that contain whitespace or other special shell characters. This could lead to unexpected behavior or errors. A more robust approach for iterating over comma-separated values should be used, for example, by using read with a while loop or by setting IFS.