Coding 2022-09-26
I was thinking about how bad it feels that I'm trying to push through covering code that I no longer fully understand, but, if I try to make the code clearer, that means breaking internal compatibility post-release, until I re-update my motrfile.
So, I can't update my code if I don't understand it, but I can't make it understandable without updating it.
Right now, I'm going to see if I can make a way around that conflict.
First off, I'm considering full test coverage non-negotiable. I find horrible bugs in non-covered lines shamefully often, so I'm going to keep that check on.
Now, going forward, I want full Pylint runs.
But here's the thing I'm going to try changing: I'm going to develop in multiple topics. Here's what I'm thinking: I branch a "future" topic off of the current horribly bloated main development topic. In that topic, I focus on documentation and code updates. Whenever I properly understand some high-level code, I switch back to the topic I'm on now, which is called, um, input-map, and appears to contain... the majority of the commits in the repository... and is nearly a year old.
All right, so first I'm going to try to close out the related bugs, make a tracking issue for test coverage, and make a new topic based off that. I'll disable pylint in the test-coverage branch, then make the "future" branch, and re-enable pylint there. This new topic is for source code changes only. Increases to test coverage go in the test coverage topic, and then get merged into future. The desired end state is that both topics pass MOTR completely, and future is descended from every commit in test coverage. That way, I can cut an 0.1.6 release from test coverage, then create a new tracking issue to update the motrfile. Merge that into future, address the conflicts, and cut 0.2.0 from the future, turning it into the past!
It couldn't be simpler! ... To gloss over a large amount of work, especially for just one developer, but whatever, I feel better about this plan than about what I was doing before.
Let's break this down a little. Regardless of what I do in the medium term, it can only improve things to clean up the state of the issue tracker and get the towncrier files in order. I'm going to just list the bugs it looks like I need to close out:
51 through 55 are questionable, and I'd rather put them in the 0.2.0 push, in that I've started on them, but I'm not entirely done until the motrfile is rewritten. Note that this is excepting 53, which is complete, and the thing that the current topic is named after. I also haven't done 66, and that kind of needs to happen at some point.
56, 57, technically 58, technically 59, 60, 62, 63, 64, 65 I think, 77 is started but I'll be able to do much better when I bump the Python version requirement.
So, it'll be pretty quick to get that housekeeping done, so I'll take care of it now...
On further reflection, I ended up only marking a few issues as properly done, but I should be able to move forward now.
Okay, I made the topics, and... I am having trouble. I forget how to make changes show up in multiple topics, or if that even makes sense, so let's see...
I'm very confused, and this might not be an intended workflow. A bunch of things I tried didn't work, so let's see if I can reason my way to something that does.
...
Dangit. I was doing everything fine, but I was getting tripped up because the "future" branch is labeled with its issue number, and I already had a documentation issue, so I just used that, so the merge commit is supposed to be in the lower number topic. This will mess something up at some point, I guess.
But yeah, this all seems to work the way I wanted it to, when I'm not making it overly fancy and confusing myself.
I think I've been trying to pack too much work into my days, so I'm going to space things out.
All right, time to wrap up. Next time I get to work on this stuff, I'm going to try out some rewrites I've had in my back pocket for months, just waiting for a chance to mess with.
Anyway, I should start winding down now.
Good night.