-
Notifications
You must be signed in to change notification settings - Fork 13.5k
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
chore: 2nd try - simplify python dependencies #27505
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #27505 +/- ##
==========================================
+ Coverage 67.39% 69.62% +2.23%
==========================================
Files 1909 1909
Lines 74736 74739 +3
Branches 8326 8326
==========================================
+ Hits 50368 52040 +1672
+ Misses 22318 20649 -1669
Partials 2050 2050
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Keeping some of the good ideas from #27404, but keeping pip-compile-multi What's left here? - keep pip-compile-multi, but bring things down to only base.txt and development.txt - reusable/simplified .github/actions/setup-backend/action.yml
8ed368c
to
3f97b48
Compare
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.
LGTM
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.
LGTM. But do we know if this could potentially break someone's deployment if they were relying on the dev dependencies for production? I'm thinking maybe the bigquery or oauth drivers.
I added a note in UGPRADING.md, but would love to get @john-bodley 's blessing before merging this one |
Great, or rather, even with the notes in UPGRADING.md, would this break semver if this is released in 4.1 for example? |
I don't think we should treat I could be great to define the things or type of things we want to treat as a public interface for semver purposes and beyond. I'd argue that pinned deps shouldn't make that list. Now with the pinned reqs keeping the package together that's a bit different, though that's why I'm trying to get back to a place where the pinned requirements would not be vital. |
Ok, merging this as I have other improvements lined up |
Keeping some of the good ideas from #27465 while putting that one on hold.
What's happening in this PR?
pip-compile-multi
, but go down to two bundlesbase.in
anddevelopment.in
, converging all oftesting.in
,docker.in
,integration.in
andlocal.in
intodevelopment.in
.github/actions/setup-backend/action.yml
for python/backend setup