-
Notifications
You must be signed in to change notification settings - Fork 70
refactor!: Drop VersionInfo in favor of tuple #124
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
6d745f1
to
80cb162
Compare
80cb162
to
a885718
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.
Honestly the way we handle version strings in this library seems very 2.x-ish. I'm all for just removing the logic and replacing it with something along the lines of this:
from dataclasses import dataclass
from packaging.version import parse
__all__ = ["VersionInfo", "version", "version_info"]
version = "3.0.0b7"
@dataclass
class VersionInfo:
major: int
minor: int
micro: int
releaselevel: str
serial: int
@classmethod
def from_str(cls, v: str) -> "VersionInfo":
parsed_version = parse(v)
return cls(
major=parsed_version.major,
minor=parsed_version.minor,
micro=parsed_version.micro,
releaselevel=parsed_version.pre[0] if parsed_version.pre else "final",
serial=parsed_version.pre[1] if parsed_version.pre else 0
)
def __str__(self) -> str:
if self.releaselevel == "candidate":
return f"{self.major}.{self.minor}.{self.micro}rc{self.serial}"
elif self.releaselevel != "final":
return f"{self.major}.{self.minor}.{self.micro}{self.releaselevel[0]}{self.serial}"
return f"{self.major}.{self.minor}.{self.micro}"
version_info = VersionInfo.from_str(version)
Or drop the entire VersionInfo altogether, since this is a feature well-supported in packaging
now. Since we are doing a major release, this shouldn't be a problem. What do you think? 😊
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.
That's what I thought too. Not a fan of maintaining our own semver parser and as you said all the logics are already implemented in packaging
.
We could keep exposing graphql_server.version = v3.0.0
and graphql_server.version_info = (3, 0, 0, "final", 0)
and keep tests using packaging
to check if version
and version_info
are spec-compliant and pointing to the same version.
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.
Sounds good, let's just do the tuple one and completely drop the version info.
to handle release candidates correctly
keep graphql_server.version_info as a plain tuple add tests using the packaging package to make sure graphql_server.version and graphql_server.version_info are PEP 440–compliant and pointing to the same version
a885718
to
f593210
Compare
Did this break something? Im trying to install the latest version of graphql-server and it is erroring with ImportError: cannot import name 'MutableMapping' from 'collections'. But when I look at the version number in my venv, it says version 3.0.0b7 |
Seems like pip can't find the correct version anymore |
Hi @fr-orionfollett could you create a separate issue for this also with a reproducible example (for example the exact commands you ran to install the library)? |
Yep, it'll take me a couple of days though |
You know what, I accidentally had two versions installed which was causing my issue, so nevermind! Thanks for the quick response though. |
Fix
VersionInfo
andtest_version.py
to handle release candidates correctly. Also refactor the tests.