Cassandra is only carbon nowWe did it! Thank you to everyone who helped make this happen!
pyreading, a set of Python packages used by Arcalibre, now builds on Linux and Windows AMD64 *and* on macOS Apple Silicon.
The Codeberg Packages feed for the repo still only has Linux glibc x86_64 wheels, but with all three CI systems up and running, I hope to expand that to publish dev builds for a much wider variety of systems.
That then means that things like icy_you, charminder, and pydofo, all of which provide static wrappers commonly used native libraries with little to no runtime requirements, should soon be available to use cross-platform.
Of those icy_you is perhaps the least exciting for Arcalibre but of the most interest more generally. Taking runtime dependencies on ICU4C is really difficult to do cross-platform. Even commercial frameworks like .NET struggle with ABI breakages in libicu versions, let alone the difficulties faced by volunteer or NPO-run projects.
By contrast, icy_you uses PyO3, Maturin, and ICU4X to statically build ICU into the Python extension module. Less efficient, so there's a tradeoff, but still.
Static linkage into extension modules is especially huge for Arcalibre when it comes to PDF support. The PoDoFo PDF manipulation library is used throughout Calibre, but it's a nontrivial runtime dependency. Thanks to @ddelemeny's amazing work, and to help from https://codeberg.org/mvanderkamp during #PyCascades sprints yesterday, pydofo eliminates the runtime dependency on PoDoFo by using static linkage instead.
Thanks to PEP 517, PDM, and build backends like maturin and scikit_build_core_conan, all of the above works cross-platform with *exactly* the same PDM commands.
Just run `pdm builld -p $wheel_name`. That's (almost) it. maturin will download Rust for you, scikit_build_core_conan has PyPI dependencies on cmake and conan... all you need outside your normal Python tooling is to have a C/C++ compiler for your system installed and on PATH.
These packages need a lot of work before they can be release ready, but the infrastructure for building, testing, and publishing them cross-platform is getting very close.
Thanks to feedback from yesterday's #PyCascades sprints, we also have a lot more insight into what barriers new contributors hit, and have some ideas on how to improve docs to help.
This is finally starting to come together, and I love it.
None of the work above is happening in Arcalibre — it's the precursor work that's needed to help make it easier to develop and work with Arcalibre.
Some of it is gaps in the Python ecosystem, like ICU4X bindings.
Some of it is stuff like pydofo, that can be used independently of Arcalibre, but is especially interesting when working with e-books.
Some of it is stuff like pyresupport_win, which has zero meaning outside of Arcalibre, but needs to exist anyway.
All of it is critical in getting Arcalibre off the ground, and so I'm happy it's coming together as well as it is.
If you want to help, dive in and get started! We really appreciate contributions!
https://codeberg.org/rereading/pyreading/issues
♥
Asta [AMP]@xgranade the amount of work you (and others) have done on this is amazing. I can't wait to start using Arcalibre!
@aud Thank you! It's still a long way off towards beta builds, but this all has been extremely helpful in removing native code from the Arcalibre code base and isolating it into packages that can be built, published, and versioned independently. The more we can do that, the easier it is to work on Arcalibre itself.
One of the biggest obstacles right now is that Arcalibre does not use a standard Python build at *all* (and for sensible reasons), so standing up the build is hard af.