-
-
Notifications
You must be signed in to change notification settings - Fork 138
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
Roadmap for future releases #249
Comments
Thanks for putting this together @mesozoic; this looks like a great plan. Would 2.x be a good time to also move ORM package out of experimental and make it officially supported?
|
Totally! Though guessing from the comments, it seems like plenty of folks are using it already, supported or otherwise 😁 so I'm still inclined to do a major version bump before changing the semantics, return types, etc. |
I am so hyped for test-related features in 3.0.0 😍 |
Great! Can you share a bit more about your use case (or existing solutions) to help inform what direction we take it? |
we have dozen of tables, couple of them having up to 200 fields, most of which are lookups, rollups and formulas. major issues with Airtable development, exploitation and testing:
|
@walkingpendulum Your use case sounds pretty complicated! So far we've avoided the field name issues by locking down Creator privileges for the bases where we've built a lot of heavy integrations. Sounds like that might not be feasible for you. We haven't really come up with a great solution to testing; we have a minimal "fake Airtable" that mocks out the API's basic behaviors in-memory, and for integration testing we have a "partitioning shim" that injects some extra formulas/fields into every API call so that multiple test runners can operate on a single base without interfering w/ each other (as long as there's a text field where they can store a unique ID per test run). Both are utilities we'd like to move from our repos into upstream. |
hello, guys! it's been a long time :) I'd like to touch base on the 3.0 feature "Testing utilities for library users to safely mock the pyAirtable API in their own tests". do you still aim for it? I am as hyped to see it as I was a year ago. also - great job done! we have moved from one-fits-all connector component that isolates AT API calls to ad-hoc pyairtable calls, because we realized how simple and powerful pyairtable is, and never looked back. thank you for your work. |
@walkingpendulum I'd still like to move what we have upstream at some point, but it's not a high priority at the moment. I'm glad some of the other improvements to the library have worked out for you! |
Is it possible for Table.all() functions to return the label/value of a Lookup field as well as the record id? |
Is it possible to enable passing parameters to the underlying request implementation when creating the Api(token) instance? For example, I need to pass in a path to a pem file. With the requests library, I do this with a |
The following is a rough proposal for which features we plan to add to pyAirtable, loosely grouped into releases. Priorities can shift over time, and anyone who wants to see a particular feature implemented faster is welcome to submit pull requests for review. I'm comfortable with the scope of the 1.5.0 and 2.0.0 releases; everything past there is a bit more speculative, but I have proofs of concept for at least some of it.
This document assumes we are using semantic versioning, and that existing APIs can only be broken if there is a major version number change. As such, we may be more cautious about implementing new endpoints (or accepting PRs for new endpoints) if the design of that API merits discussion, because we'll commit to supporting new APIs for at least one major version.
Tagging other recent code contributors for input. @BAPCon @goksan @larsakerson @NicoHood
1.5 (released May '23)
This release will focus on bug fixes, quick wins, and reducing the open issue count.
POST /listRecords
instead ofGET
when the URL gets too long #247 (see 203, 210, 222)2.0 (July '23)
This release will be our chance to make any breaking API changes, such as changes to default behavior or return types. We will also implement stricter typing across the library, which might break CI for downstream code that does its own type checking, and support every field type in the ORM.
validate_type=
parameter toField
constructormypy --strict
#263 (see 202)dataclasses
orTypedDict
on all return valuesurllib3 >= 2
#251ApiAbstract
#267time.sleep
#272api.whoami()
#273 for Get user ID & scopes2.1
Just a plain ol' feature release.
2.2
Build a sustainable pattern for retrieving with Airtable metadata, which involves a lot of deeply nested object structures.
2.3
3.0
Next major version bump after 2.0 can be for bigger ideas.
4.0
Won't do
The following wound up being a lot more work than we'd anticipated.
pyairtable
anddocs/source
on build.The following seem like uncommon use cases and we'll wait for another contributor to need them.
SCIM is a standard API specification that is already implemented by any vendors which need to support it, so implementing it in pyAirtable doesn't seem like a priority.
The text was updated successfully, but these errors were encountered: