-
Notifications
You must be signed in to change notification settings - Fork 0
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: update fourmat dep #38
base: master
Are you sure you want to change the base?
Conversation
setup.py
Outdated
@@ -26,7 +26,7 @@ | |||
extras_require={ | |||
"dev": [ | |||
"pytest", | |||
"fourmat~=0.11.1", | |||
"fourmat~=1", |
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.
Loosening restriction since this is a library.
Consuming projects should pin this if desired.
Previously we pinned it, rationale being that black
is a sub-dependency of fourmat
and it could have breaking formatting changes. However, it might be better to have consuming projects pin if desired?
Thoughts?
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.
@c0state seems the fourmat
lib pins a specific version of black
: https://github.com/4Catalyzer/fourmat/blob/master/setup.py#L28
fourmat
also appears to be following a convention of introducing a new major release version whenever the pinned black
dependency major version changes. This makes sense, as bumping the major version of black
could produce breaking formatting changes. So I think we can reasonably assume that breaking changes to formatting behavior only happen when using a new major version of the fourmat
lib. Haven't verified this, but that seems to be the intention.
Since we only expect breaking changes in fourmat
major versions, loosening the restriction as done here makes sense. Even if a breaking change was inadvertently introduced into fourmat
at a minor/patch level, a consuming project could get around this by pinning a specific fourmat
.
Something to consider is that the change of fourmat
from 0.11.1
to 1.x.x
may include breaking formatting changes, since the black
major version bumped (4Catalyzer/fourmat@v0.11.1...v1.0.0). fourmat
is only used in a dev context, so it's unclear if we should bump the version of TQP itself to account for this.
Also, apparently ~=1
isn't valid per PEP. Should probably change it to
"fourmat~=1", | |
"fourmat~=1.0", |
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.
Also, apparently
~=1
isn't valid per PEP. Should probably change it to
...
Ah, was looking at poetry docs https://python-poetry.org/docs/dependency-specification/#tilde-requirements, which I assumed would be the same, but are slightly different apparently. edit: misread that, poetry doc was for ~
, not ~=
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.
Something to consider is that the change of
fourmat
from0.11.1
to1.x.x
may include breaking formatting changes, since theblack
major version bumped (4Catalyzer/[email protected]).fourmat
is only used in a dev context, so it's unclear if we should bump the version of TQP itself to account for this.
Agreed--this isn't addressed in this PR, but we should update the (minor, I think?) when we cut a new build. That process was manual when 1.0.0
was pushed IIRC, since Travis integration is currently broken. I reached out to re-enable it for this public repo, but that isn't yet fully resolved.
Co-authored-by: matt-mclaughlin-quantum-si <[email protected]>
No description provided.