Newish user and new contributor here. I had a couple of questions that may have already been taking into consideration, but I am curious if any of them got captured.
My first question is has the community considered using “Squash and merge” vs “Create a merge commit” on PRs via GitHub? Cleans up commit history pretty well. It also allows the project to not get bogged down with bloat-y intermittent commits (e.g. fixed typo, changed variable).
And my second question is kind of a doozy. Have we ever considered moving beets from Python to JavaScript? I’m curious as to original direction and what the current direction is. I can’t say with confidence but if we migrated to JavaScript it could generate more contributors; along with performance increases. We would still have all of the core functionalities that exist today and includes potentially better capabilities:
Use a strict linter with JavaScript so we can follow guidelines like PEP8. E.g. ESLint
Or the use of TypeScript (see below)
Better asynchronous design patterns, but still can use all the design patterns Python offers (builder, factory, DI, observer, etc.)
Potential use of multi threading (depending on what version of Node.js is used)
This same argument could be used for C++/C/Golang. But to keep the conversation relevant, I’d say Node.js (with JS or TS) with Golang as a runner up could be good tools to scale beets.
Anyway, just my two cents. Just wanted to see where the dev community was at .
Hello! And thanks for your helpful addition this week!
Here are a few quick thoughts on these matters.
On merging vs. rebasing vs. squashing: I don’t have a strong opinion about this. Folks are of course welcome to rebase if they like, or even to manually squash. I don’t mind much in any particular direction. I tend to favor proper merges for two reasons:
I don’t see any real downside to a “messy” commit history. It might look complicated in git log --graph, but it’s not really doing anyone any actual harm to have all those typo commits.
It preserves “true” history better. That is, unlike rebasing, it shows what actually happened: a person diverged from master by committing on top of an earlier commit, and then had to reconcile their changes with the latest master. Rebasing makes it seem like the work happened at a different, later time when it really didn’t.
Anyway, I don’t really care much either way because I don’t think the structure of the history graph matters all that much.
I would, however, very much oppose a move to JavaScript. The two main reasons are:
I enjoy programming in Python quite a bit more.
We have way too much stuff written already to make a rewrite feasible.
To the second point, I just did a fresh line count of the project, and we’re at 55,671 lines (not including blanks and comments). That would be a truly tremendous amount of work to rewrite! It has taken countless volunteers more than a decade to write beets. I think it would take me at least several months of full-time work to rewrite it. I really don’t think it’s possible to do this all in one go, even if we desperately wanted to move.
If you’re interested in checkers, FWIW, we got 'em! The flake8 style checker and linter is enabled in CI. And while we haven’t really embraced mypy types yet, we could certainly do that. The type system isn’t quite as nice as TypeScript, but it’s pretty cool—it’s worth checking out if you haven’t seen it!
That I totally understand. I see that the project took off with Python and why it would diverge from that wouldn’t make much sense. Thanks for the detailed response.
I’m going to look into those libraries and see if I can find myself useful.
.