-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Remove agate dependency? #3413
Comments
We can't estimate this right now. Instead, let's spike:
Some options:
|
@drewbanin I'd be curious to hear what sticks out as the really bad parts of relying on agate. The two issues I outlined above have both been resolved:
The biggest downside for me is, we'd want to keep the dependency tightly pinned, since the maintainers have a history of including breaking changes in patch releases (e.g. coercing bools into numbers). |
@jtcohen6 I'm with you that the big downside risk is around pinning the dependency. It would be unfortunate if a dependency of |
This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please remove the stale label or comment on the issue, or it will be closed in 7 days. |
Hiya, I took over maintenance of agate a little while ago. Which patch coerced bools into numbers? Anyhow, semantic versioning should be fine going forward. agate accepts PRs if you need anything :) |
Describe the feature
As time goes on, our reliance on the
agate
package for light-weight data frames may be providing us more grief than gain.agate
causes headaches in the RPC server (rpc returns empty string values as null values #2666, RPC server sometimes returns the wrong type #2984), and it necessitates one of my least favorite configs, seedcolumn_types
overridesagate
to an older version to avoid a second-order dependency that bricks a lot of installation (dbt==0.18.1
Package failing to install starting on March 10, 2021. #3160, Pin agate<1.6.2 to fix installation #3161)That said, there's still a lot
agate
does get us:print_table()
(docs)Any changes we make here have a lot of potential visibility and surface area.
Describe alternatives you've considered
I'm not sure... are there other packages that could occupy the same niche for us? Is this something we should look to hand-roll? I'm not convinced that the problems we're encountering, especially around data type inference, have "easy" solutions, if only we could be writing the code for them ourselves.
Additional context
This affects all databases. While
agate
functionality is obscured from many users, I imagine that a nontrivial percentage of the overall user base depends onagate
-specific methods today, whether via their own Jinja code or by leveraging macros from a package.I'm adding this to the v1.0 list, not because we should definitely do it, but because we should consider whether we can comfortably include the current
agate
dependency in our stable major-version release.Who will this benefit?
run_query
are wrapped in more mystique today than they ultimately should be. Whileagate
provides an okay syntax for working with query results, it's not ideal. Along with work aroundexecute
, we could improve the experience of templating model SQL based on the results from introspective queries.The text was updated successfully, but these errors were encountered: