Max Woerner Chase @mwchase@im-in.space
- Three Dollar Quill
- https://mwchase.neocities.org/
Joined May 2019
Pinned post
A lot of my bandwidth for personal projects recently has been taken up by #MOTR. Basically, I got tired of copying and futzing with https://tox.wiki/en/latest/ config, so I switched to https://nox.thea.codes/en/stable/. Then, I got tired of copying and futzing with *that* config. So, I started working on my own replacement, that makes a few different decisions so it can do stuff like run unrelated tasks concurrently, but it's configured by a Python file.
Question for lazyweb... I've been having issues with indentation in #jupyterlab. I reached out to CodeMirror about some of the feature requests I had, and got told "You could consider writing a custom command to bind to enter that implements the behavior you want here." I'm willing to do that, but I'm a little unclear on how to accomplish this in the context of #jupyter. Is this, like, an application plugin, that I write in TypeScript (I do not know TypeScript but I'm willing to learn for this.), and somehow I need to provide a callback that interacts with CodeMirror?
Is this all a thing I can even *do* like this? If so, what entry points should I be using, and if not, how should I accomplish the task of "make CodeMirror work different in Jupyter Lab"?
I just realized I made an off-by-one error with the caption. It's actually seven levels of indentation.
Doing penance for my Software Architecture Crimes.
So, I tried to implement the code needed to make the tests pass in #MOTR, and, um...
I *think* there's some stuff in there that can get factored out? But right now I'm staring at it and hearing bass-boosted Somebody That I Used to Know.
Old timey operator precedence was CURSED https://www.kmjn.org/notes/operator_precedence_fortran.html
This one is a little bit more elaborate. I've got some common code in three tests, but rather than lifting it to the top level, I want to provide equivalent functionality through the API instead.
Let's see...
I just put together a first stab at this by making a simple wrapper class around one of the constants. There's still some room for improvements in the modules themselves, but that's a lower priority compared to improving the interface.
I just now rewrote the tests to use the new interface, and they passed! Very good.
The new interface is a little weird. Could be better.
I'm going to wrap up for now, but the next step is pretty clear, I think: work on the names for the unreleased API layer, so I don't have what feels like five different things called Argument, Command, Static, etc.
And just, toss together a fixture to create a factory...
(This level of indirection wouldn't be required if I didn't have a very particular habit of how I structure my tests, but I don't care to change that habit.)
Initial attempt had a test failure because I missed a level of indirection. Added it back in, and, rerunning... Okay, that's much better. Let's see about those flake8 issues I was expecting... Ah, just one issue.
All right, that's all set. Let's see about the other one.
There are two basic areas that I want to try to improve for now. The straightforward change is to make a helper function for the tests, because that way, I should be able to eliminate a partially run line from the coverage report. The other one is to take some of the common test code, and move it into the package in a reusable form, so that I can later work on related tests without worrying about wanting to rewrite them as much later.
Let's improve some of #MOTR's test code!
Just got jumpscared by a Sublime Text extension update notice in the middle of editing some code.
Hm. Waiting for my link to verify. I did only just now update the HTML, so.
Anyway, I guess it probably makes sense to unlist the toots in my MOTR threads so it's just the top level ones that go out.
I'm really tempted to just add an argument to these methods, and invoke the maps in a loop.
It can't be worse than the current state of things.
But it's too late to do more tonight, so I'm going to wrap things up ASAP.
Looks like I've built a bit of a maze for myself. Let's look at each end.
On the external interface side, I need to have some way of saying "for executing flake8, use the current python interpreter".
On the internals side, we have, working outward:
CmdMeta is missing an appropriate EnvironmentArgs for the purpose of "resolving".
The CmdMeta is constructed in a Command's "requirements()" method, which is invoked...
In a lambda in the test code, that is passed to the "map()" method of a Dynamic that is constructed from an Invocation.
Now, I think I had some idea that this data was supposed to live on the Invocations, so I should have a look at that class...
Okay, that goes back around to Command.with_module... well, I'm confused.
Circle back to the usage of Dynamic.map(). This method derives an Items iterator from an Objects, and is what converts one thing into many things.
So, the question I have to answer now is, how does the list of interpreters get into all of this?
The bug I mentioned from #MOTR last time is, I keep on forgetting that inheriting from a protocol does not automatically make the subclass a protocol. You have to inherit from Protocol explicitly.
Anyway, I could try various ways to continue on with what I did last time, but I think I'll just rip out the old protocol and throw myself on the mercy of the typechecker.
Okay, here we go.
Delete Installer, TInstaller, and replace the Registry definition with "Registry = _typed_map.TypedMap[UnlabelInstallerArgs]".
This is going to get all kinds of messy before it even leaves the file, but such is the price of progress.
There's a bug in the code snippet in that post. I'm hoping to use this toot as a reminder to note it later.
All right, here's the post capping things off for tonight: https://mwchase.neocities.org/coding-2022-04-18.html
Hm. It's a little sus that MOTR's progress bar doesn't update if nothing is completing. I should check how tqdm works, but it would be nice to have stuff moving once a second at least...
It's probably worth noting that I'm manually driving the meter, because there's no obvious way to me, to represent this as an iterable. I'm going to put in a ticket with myself to add an update event every second.
All right, I'm back. Just made the two subclass protocols required by this plan, but I forget exactly what goes in them. Time to refer to my notes.
Okay, the notes are outdated, even though I only took them a few days ago. Okay, okay, fine, let's see where I can go from there.
I'm going to write another class to handle this. Maybe it'll become a protocol later, maybe it won't.
I just got held up a bit coming back to the same question I've been wrestling with about which part of the code should be responsible for which things, when it comes to setting up the environments, and this new class to *represent* the environments has gotten me somewhere that at least feels more correct than what I had before.
