In this post:
- I look at all of my GitHub repositories from the last few years, and try to cut down on the cruft.
After working on composition software suddenly got me to release a reworked version of an old hobby project on GitHub, and do three releases of some other code in the space of a day, it occurred to me that I should write up all the software that I'm actually vaguely willing to take responsibility for.
On GitHub right now, I have:
Stuff I want to develop more in the near future:
- python-structured-data: the code that I spent all of Sunday getting into a state of "no tests whatsoever, and what documentation exists is somehow outdated in places". Because it would improve some of my code right now, I'm really interested in getting it into a usable state, and writing mypy and pylint plugins so I can use it without having tox fail. In terms of supported versions, it should be able to offer partial functionality from 3.5.?-3.6.5, and full functionality from 3.6.6+.
- divide-and-cover: should really be two repositories, probably. divide-and-cover is a wrapper around Coverage.py that exposes hooks to switch between multiple command-line executors, which is useful because it lets you define one executor per module, designate tests as applying to a particular module (with auto-discovery), and only collect coverage data in the source tree during an initial import step, and when you're running tests that target a particular module. This has the effect of localizing the coverage from a test module, so it's relatively straightforward to tell which test covered which line, and encouraging modules to have well-defined interfaces that can exercise all of their internals. The actual logic of what to create and when to switch is handled by plugins to test frameworks; currently there's a pytest plugin. It would be nice if the code, now that it's testable, could be tested on all supported versions of Python, or at least every version supported by Coverage.
- class-namespaces: Inspired by a blog post that I believe was targeted at Python 2, a Python 3 library that allows you to divide a class namespace into more namespaces, to represent situations where one class has multiple responsibilities. This is some pretty cool code, although nobody uses it that I know of. I've been meaning to remove some unneeded code, update the testing matrix, and look into using divide-and-cover. I want to look into writing plugins for static analysis tools so they don't get confused. It would be good to test this against all supported versions of Python 3.
- jedi: I forked this to work on a PR to add support for typing.NewType, and I keep on not working on that. But I want to do it, because it would be really useful.
Stuff that I could potentially get back to developing...
- log4l: "This branch is 72 commits ahead of Neopallium:master." ... Wow. I forked lualogging because it had all sorts of outstanding bugs and pull requests (protip: If you interact with an interface in version X, and it gets removed in version X+1, the null hypothesis is that it won't be back in version X+2. Just saying.), used it a little, and promptly stopped using it. I wouldn't say no to updating it if it ever has any active users, including me, but right now, I don't have any issues or pull requests to deal with on it. (Although someone did file an issue against lualogging the day after my most recent commit to log4l.)
- lua-lineread: Did I ever push this? I guess not. The code on my laptop appears to have been adapted from a module from the Luvit Invention Toolkit.
- lua-cmd: An attempt to port the Python stdlib cmd module to Lua. I ended up not pursuing whatever project I was writing this for, so it's in limbo right now.
Stuff that I'm definitely not going to do anything with in the foreseeable future. (I archived all of these repositories after I made this list.)
- cpython: I forked it to make a PR for some bug or other, then never actually got to the "writing a PR" part
- Psi: forked over a year ago in an effort to investigate a crash that I kind of hope is fixed by now
- ink: I think I forked it to make a PR for a bug fix?
- test-box: the ideas behind this later went on to become divide-and-cover
- super-duper-adventure: I played GitHub roulette two years ago, and tried (not very hard) to make some interactive fiction
- unrest-tooling and project-incipience: I assume the whole "let's try to make a Mass-Effect-like in Unrest's engine" idea isn't a thing right now, but I wouldn't say no to helping out with a completely fresh effort helmed by someone better than I am at project management, which seems like a low bar.
- unrpyc: I think this was also a fork for a bug report.
- md-haxebinding: I think I was trying to fix a bug???
- haxe-titanium-api: I don't remember why I forked this, except that I never do as much mobile development as I have thought, at times, that I might potentially do.
Just on my laptop, I've got a bunch of repositories, but the stuff I want to work on in the near future is:
- Conworld Codex: I've got a good feeling about its direction, and unlike the other two, it doesn't have a pressing need for Structured Data.
- Homunculus: would benefit from Structured Data, but it's not super necessary.
- Tiny Music: on hold until Structured Data has had a few more updates.
And not yet made, I have plans to do a mixture of forks and PRs for cookiecutter-pylibrary.