-
Notifications
You must be signed in to change notification settings - Fork 18
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
utils.py: fix yaml output #72
base: main
Are you sure you want to change the base?
Conversation
Fixes bug: getpatchwork#70 with incorrect output for 'Patches' property in .yaml format. Signed-off-by: Oleg Ananiev <[email protected]>
I'm still not the maintainer but "fix yaml output" doesn't really explain what or why the changes are happening. Please explain in the commit log what the intention of the change is. |
Sure, I am okay with writing a more detailed explanation. The question is where will be the best place to do it? Should it be written as comments inside the code or written as a commit message or ...? Right now I don't see any comments in either the code itself or the commit logs. Stephen, what will be your preferences as a maintainer? |
Comments in the code, please. I suspect this might not be the right approach, however. You'll see we're transforming the response from the API before we call the output functions (e.g. import abc
import arrow
class Field(abc.ABC):
def __init__(self, value):
self._value = value
@abc.abstractmethod
def human_readable(self):
...
@abc.abstractmethod
def machine_readable(self):
...
class DateField(Field):
def human_readable(self):
return arrow.get(self._value).humanize()
def machine_readable(self):
return self._value
... From a quick look, we'll want a field type for boolean values, submitters, users, and projects. There may be more. I'm open to other suggestions also, but I do think we want to avoid transforming data before we attempt to output it. |
Pardon, Stephen. I am a bit confused on what you answered. |
Hello, Stephen. On January this year, I have made a commit, fixing the bug in for the output Patches' property in .yaml format. Since then, you have not told me what will be your preferences as a maintainer, and I am a bit confused on what you commented on January 25th. Can you please tell me what exactly are your preferences and tell me if there are any issues with the commit that I have submitted? Thank you. |
I don't think what we've done here is sufficient. What I was trying to say is that the data we pass to the
This is the current output for
But we probably want to expose a richer format closer to what we get from the API. Something like this:
I'm open to idea on how we can do this. My suggestion above was to wrap the unserialized data in formatter classes (so a datatime-style field would get wrapped in a datatime formatter) and pass this wrapped, unserialized data to Hopefully that's a little clearer. I don't know if this is something you'd be comfortable doing. I did have a solution started on this way back but I have yet to finish it, unfortunately. |
Fixes bug:
#70
with incorrect output for 'Patches' property in .yaml format.