source-google-sheets: use poetry for dependency management

[alafanechere]

What

Closes #34954

We want to make our connectors use poetry for dependency management (see tech spec)

This PR is migrating source-google-sheets, a certified connector, to poetry.
The changes were generated by a new airbyte-ci command I'm currently working on (PR to come).
The idea is to get early feedback and address problems on the migration flow if any.

How

• Create pyproject.toml and poetry.lock
• Pin main dependencies to the version used in the previous connector version
• Delete setup.py
• Update connector README.md with new instructions

🚨 User Impact 🚨

please note that, unlike setup.py based packages, packages managed with poetry must declare the version of python with which they are compatible. I picked ^3.9 which means the connector can work on Python 3.9 or higher (3.10).
It's a requirement to work with airbyte-lib as:

• airbyte-lib python dependency is also ^3.9, which means airbyte-lib is not forcing users to use an old python version in their environment.

Our base image is still based on Python 3.9.18 which means the released connector will still used a consistent python version.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
airbyte-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 8, 2024 9:04am

[alafanechere]

• master
  • airbyte-ci: only install main dependencies when calling poetry install #34945
    • source-google-sheets: use poetry for dependency management #34944 👈

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @alafanechere and the rest of your teammates on Graphite

[github-actions]

Before Merging a Connector Pull Request

Wow! What a great pull request you have here! 🎉

To merge this PR, ensure the following has been done/considered for each connector added or updated:

• PR name follows PR naming conventions
• Breaking changes are considered. If a Breaking Change is being introduced, ensure an Airbyte engineer has created a Breaking Change Plan.
• Connector version has been incremented in the Dockerfile and metadata.yaml according to our Semantic Versioning for Connectors guidelines
• You've updated the connector's metadata.yaml file any other relevant changes, including a breakingChanges entry for major version bumps. See metadata.yaml docs
• Secrets in the connector's spec are annotated with airbyte_secret
• All documentation files are up to date. (README.md, bootstrap.md, docs.md, etc...)
• Changelog updated in docs/integrations/<source or destination>/<name>.md with an entry for the new version. See changelog example
• Migration guide updated in docs/integrations/<source or destination>/<name>-migrations.md with an entry for the new version, if the version is a breaking change. See migration guide example
• If set, you've ensured the icon is present in the platform-internal repo. (Docs)

If the checklist is complete, but the CI check is failing,

1. Check for hidden checklists in your PR description

2. Toggle the github label checklist-action-run on/off to re-run the checklist CI.

[flash1293]

LGTM from the airbyte-lib side - validated locally and it works as expected

[girarda]

docs changes look good to me, but I haven't tested the new commands ✅

[natikgadzhi]

I like this!

Re: python version — I remember @girarda mentioned that someone reported a bug in the CDK when running a newer Python, and I'm very curious to look at what an upgrade to 3.12 could give us.

This would not be an urgent project, but I would like the cleaner typing syntax, and the performance improvements — and would love to see how much of performance gains we can get overall when the CDK and all connectors and our tools switch.

Another prereq for this might be to start testing connectors with Pythons matrix from 3.9 to 3.12.

[natikgadzhi]

Wow, the previous version here weirds me out. Was it just a completely wrong doc?

[alafanechere]

Yes it was ...

[natikgadzhi]

Why hard pin? I get it if we're just moving from setup.py as it was, but figured in theory we want to unpin most dependencies to major get at least patch / minor version upgrades for free?

[natikgadzhi]

My take is that Poetry.lock gives us the deterministic build, but the actual dependency list should be as flexible as possible. If it was previously hard-pinned in setup.py, it might be because we were trying to do the lock thing with the deps list. I would try and err on the side of unpinning.

Perhaps, though, this should be another step after this all is done. For example, note that the CDK is pinned. I don't think we should unpin it right now, that might cause issues ;)

[alafanechere]

@natikgadzhi the idea there is to force this new connector version to have the same dependency version as the previous one. Even if the previous version was not pinning a version I want to pin main deps in this newest version to guarantee no regression.
These pins can be relaxed without issues in upcoming PRs if needed.