-
Notifications
You must be signed in to change notification settings - Fork 10
Upgrade versions, remove tox from README, update maintainers #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
Conversation
pyproject.toml
Outdated
| source_dirs = ["tests"] | ||
|
|
||
| [tool.coverage.report] | ||
| fail_under = 90 |
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.
Oh I see you added this. I'm kinda meh on this but we can deal with it later if it ends up being annoying.
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.
Happy to revert this because I'm not really sure about it either.
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'm also kinda meh on having this checked into source control. It makes sense for an application, but not a library IMO. I agree with astral-sh/uv#9797 (comment)
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.
There's a small performance and reproducibility benefit to it being in source control, especially now that we're using uv on CI.
What makes yous uncomfortable about it? Is it the bigger diffs? Are you worried about someone sneaking in dependencies under our noses?
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.
Mostly the noise in PR diffs. Maybe if you could keep uv.lock changes in their own PRs it would help to avoid distracting me in PRs unrelated to dependency changes.
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.
Makes sense. I'll keep dependency changes in separate PRs going forward.
Co-authored-by: Nathan Goldbaum <[email protected]>
No description provided.