Skip to content
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

Handle issues as dict rather than Issue #1037

Merged
merged 3 commits into from
Mar 27, 2024

Conversation

ryneeverett
Copy link
Collaborator

No description provided.

Only the completion_type and target are ever used.
There's not much point in passing Issue instances to db.synchronize
because it was immediately converting them to dictionaries anyway. Now
db.synchronize's conception of issues is purely in dictionary format.
https://docs.python.org/3/library/stdtypes.html#mapping-types-dict

We're no longer relying on implicit `dict()` conversion and are rather
using the `get_taskwarrior_record()` method directly.

I assume the original motivation for this was convenience of use in
third-party applications which used bugwarrior as a library. As far as I
know no such applications are still in use.

In preparation for documenting and stabilizing the base class interfaces
(GothenburgBitFactory#791) I'd like to cut them back to a minimum. Maybe the mapping type
could be added back some day if there were demand for it, but it would
then need to conform to a standard of testing a documentation I plan to
implement.
@ryneeverett ryneeverett merged commit 20972fb into GothenburgBitFactory:develop Mar 27, 2024
36 checks passed
ryneeverett added a commit to ryneeverett/bugwarrior that referenced this pull request Aug 24, 2024
In preparation for stabilizing the base classes (GothenburgBitFactory#791), I'm moving these
methods which child classes never need to call to a separate class in
the collect module.

We *could* leave them where they are and just make them private methods,
but at this point I think slimming down the base classes as much as
possible is our best bet to being disciplined about their stabilization.
This not only removes lines of code but I believe the entire class of
would-be private methods.

I also removed the __str__ and __repr__ methods, which depended on the
get_taskwarrior_record method. These used to be used in logging messages
in db.synchronize but since GothenburgBitFactory#1037 db.synchronize is receiving dict's and
not Issue's. (The usages in that method are presently mixed between
logging `issue` and logging `issue['description']`. The logs could be
improved by switching the remainder to the latter.)
ryneeverett added a commit to ryneeverett/bugwarrior that referenced this pull request Aug 25, 2024
In preparation for stabilizing the base classes (GothenburgBitFactory#791), I'm moving these
methods which child classes never need to call to a separate class in
the collect module.

We *could* leave them where they are and just make them private methods,
but at this point I think slimming down the base classes as much as
possible is our best bet to being disciplined about their stabilization.
This not only removes lines of code but I believe the entire class of
would-be private methods.

I also removed the __str__ and __repr__ methods, which depended on the
get_taskwarrior_record method. These used to be used in logging messages
in db.synchronize but since GothenburgBitFactory#1037 db.synchronize is receiving dict's and
not Issue's. (The usages in that method are presently mixed between
logging `issue` and logging `issue['description']`. The logs could be
improved by switching the remainder to the latter.)
ryneeverett added a commit that referenced this pull request Aug 30, 2024
In preparation for stabilizing the base classes (#791), I'm moving these
methods which child classes never need to call to a separate class in
the collect module.

We *could* leave them where they are and just make them private methods,
but at this point I think slimming down the base classes as much as
possible is our best bet to being disciplined about their stabilization.
This not only removes lines of code but I believe the entire class of
would-be private methods.

I also removed the __str__ and __repr__ methods, which depended on the
get_taskwarrior_record method. These used to be used in logging messages
in db.synchronize but since #1037 db.synchronize is receiving dict's and
not Issue's. (The usages in that method are presently mixed between
logging `issue` and logging `issue['description']`. The logs could be
improved by switching the remainder to the latter.)
NexAdn pushed a commit to NexAdn/bugwarrior that referenced this pull request Sep 19, 2024
In preparation for stabilizing the base classes (GothenburgBitFactory#791), I'm moving these
methods which child classes never need to call to a separate class in
the collect module.

We *could* leave them where they are and just make them private methods,
but at this point I think slimming down the base classes as much as
possible is our best bet to being disciplined about their stabilization.
This not only removes lines of code but I believe the entire class of
would-be private methods.

I also removed the __str__ and __repr__ methods, which depended on the
get_taskwarrior_record method. These used to be used in logging messages
in db.synchronize but since GothenburgBitFactory#1037 db.synchronize is receiving dict's and
not Issue's. (The usages in that method are presently mixed between
logging `issue` and logging `issue['description']`. The logs could be
improved by switching the remainder to the latter.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant