-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Python sources refactoring #592
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like this!
!Dockerfile | ||
!base.py | ||
!airbyte_protocol | ||
build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use the exclusion pattern for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question :) we want to have a small context sent to docker for our core piece since we don't want to pull all the compiled and dist files but for connectors, having it it as an exclude list is very confusing to someone who tries to create a new connector since it becomes yet another place that you need to update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright sounds fine. We will have to be careful once these have python tests though, potentially with secrets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not a problem. they won't end up in the image just in the context used to build the image
!base_singer/__init__.py | ||
!base_singer/singer_helpers.py | ||
!setup.py | ||
build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as above
"type": "object", | ||
"required": ["start_date", "base"], | ||
"additionalProperties": false, | ||
"properties": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the example properties here shouldn't belong to the exchangerate api
from base_singer import SingerHelper | ||
|
||
|
||
class TemplateSingerSource(Source): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also feels like it shouldn't be based on the exchange rate api. Either we should actually use the exhangerates api as the template we point devs to or we should use something that won't diverge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed. Let's take that conversation to the other PR with the singer shim
airbyte-integrations/base-python/airbyte_protocol/entrypoint.py
Outdated
Show resolved
Hide resolved
Co-authored-by: Jared Rhizor <jared@dataline.io>
What
Few refactorings:
spec
there should be no behavior changes
Checklist
egg-info
files in build (future PR)Recommended reading order
base-python
base-singer
template/python-source