Initial commit of python-orjson
Dependency of anki
Depends on D10851
I can further investigate when I get home if this is a no go. Maybe there is a chance that our Rust is new enough that with a modification of the build scripts it will compile anyway. But then again anki itself also downloads a nightly version during its build.
So, the orjson build makes use of the "mutable-noalias=yes" option, which is only available in nightly versions of Rust. If we were on LLVM 12 I could simply remove that option since Rust defaults to mutable noalias with LLVM >= 12, but right now the nightly version of Rust is the only way to set it as orjson wants it. Of course, I could simply patch that out and ignore it, since it's just an optimization. Thoughts?
@DataDrake So I tried to patch it out but as it turns out it doesn't just depend on the nightly toolchain for the minor "mutable-noalias=yes" option, but in a more subtle way by using dependencies that require features of Rust nightly. Patching some of those features out went a little further, but now I have arrived at dependencies of dependencies that use nightly features, and also at a point where I can no longer guarantee that some of those nightly features aren't necessary for the proper function of python-orjson in some regard.
So, since I either have to test and patch several very old orjson versions or download the rust nightly toolchain, I have decided to not package this after all. During my research I found out that anki includes a workaround for systems without orjson, and will work fine. pip will still complain about an unmatched dependency, but there should be no user-visible issue (and no issue ever manifested itself in my tests)
As soon as Rust implements some of the required features in stable and our LLVM is updated for the no mutable aliases feature to work, I will take a look at packaging it again.