That makes a lot of sense, thanks for your comments! And yeah, I’m pretty much coming from that the work of getting to a stable build is pretty difficult to carry out without making substantial changes to the code base, such as removing RapydScript-NG. Given that, I think maintaining and developing Arcalibre as its own project rather than trying to stabilize a Calibre build is probably a lot more feasible.
I’ve looked into Python/WASM as a possible plugin mechanism to allow either non-Python plugins, or decoupling plugins from the venv used by Calibre itself, and it definitely seems feasible? That said, some of the RS code seems to go into web contexts that may or may not yet support WASM, I don’t know how well QtWebEngine plays with WASM at moment, most of what I’ve seen goes (weirdly enough) the other way, embedding Qt in WASM contexts.
I really like the idea, but I think I fall more towards what you note, that it’s more risky at this point than TypeScript, and a higher bar to contribution.
Yeah, no, a lot of this comes back to the “what should Arcalibre be” question, but I’m increasingly getting to the point where an archival fork doesn’t make as much sense as I’d have hoped. The Calibre codebase is really fragile, and in ways that make it difficult to snapshot without making significant changes. I’ll say more in the other thread shortly.
In any case, yeah, TypeScript seems like a good path forward. It’s a much lighter-weight and better-maintained dependency (even if it is Microsoft). There’s a lot of JS code in the form of .pyj modules, such that having some compile-time guarantees makes a lot of sense.
Similarly, I like the idea of replacing modules one at a time. I’ve not gotten the tests down to a point where I can run them, but hopefully the existing test suite should help in porting RS → TS?
It’s both, but when run as a build dependency, it’s used with a custom QPA engine ("headless") that seems to have troubles lying to QtWebEngine about Vulkan support. I would guess that the rationale is that since QWE was already a runtime dependency, re-using it in a headless build context was probably reasonable at the time.
As another addendum, I’m significantly more convinced of the need to decommission RapydScript-NG after seeing that it’s effectively a vanity fork by Kovid, and very likely to be modified in ways that break Arcalibre in the future. In general, I think it’s a good strategy to cut dependencies on Kovid’s other projects such that Arcalibre can be independently maintained and developed.
Maybe taking things kind of in synthesis, going to Loomio might make sense once things are bigger — until then, for keeping records of decisions, maybe something like recording governance decisions in issues and PRs on rereading/governance makes the most sense?
Thanks for kicking this off! And yeah, I think it’s a great idea to kind of brainstorm what some new features might be, especially if we decide to reposition Arcalibre as more than an archival fork.
Some initial thoughts off the top of my head:
One other possible copyleft license, pointed out by /u/zkat@toot.cat, would be the Parity Public License. Like the GPL family, Parity looks to require copyleft-style contributions, but allows contributions to be under a weaker license than Parity itself as long as that license grants the user at least as much privilege as Parity itself does.
Contribute
To contribute software:
- Publish all source code for the software in the preferred form for making changes through a freely accessible distribution system widely used for similar source code so the contributor and others can find and copy it.
- Make sure every part of the source code is available under this license or another license that allows everything this license does, such as the Blue Oak Model License 1.0.0, the Apache License 2.0, the MIT license, or the two-clause BSD license.
- Take these steps within thirty days.
- Note that this license does not allow you to change the license terms for this software. You must follow Notices.
That also has the quite nice advantage of not being as strongly tied to the FSF, which is a quite problematic organization to say the least. Definitely a good option worth considering!
As a quick addendum, I forgot to note that the RapydScript-NG compiler currently is shipped as a partially minified blob that is then used to self-host the compiler build (as per bin/rapydscript --self). That in turn adds complexity to the task of removing the implicit dependency on opaque blobs.
Ah, thanks for pointing that out! I’ll take a look at fixing that today, but in the meantime, the project blog is up at https://blog.rereading.space/, and should have an RSS feed at https://blog.rereading.space/feed/.
No, yeah, that makes sense. I think getting Arcalibre to the point where it’s usable from a local Nix environment and then focusing on splitting modules out is probably the best path forward for now. Trying to make a Flatpak for Arcalibre turned out to be an immensely frustrating experience, as existing Calibre Flatpaks are based on tarballs that have a lot of extra stuff vendored in, and that are only available for the latest release — making a Flatpak that is reproducible from the source alone is much harder. Focusing on splitting out modules into wheels that can be built independently should make that a lot easier, rather than committing to the work of making a single monolithic Flatpak.
Awesome, thank you so much! I started working on getting unit testing up and running in case that’s helpful to an RS → TS port.