Decision on #272/#273

[mara004]

Decision on #272/#273

Let me inform you that I have reached the (provisional) decision of not adding any dedicated code for the use case raised by @nh2 in #272/#273 to pypdfium2 after all. It is based on the following assessments (among others):

• We do not desire to, and see no sufficient justification for adding code to pypdfium2 itself to specifically install offline from a pdfium-binaries archive only (i.e. without remote headers or version refs), because it too niche a use case: Distros will want to (rsp. are better advised to) unbundle pdfium and share it at system level, meaning the pdfium binary would not be managed through pypdfium2.
  Moreover, distros do not usually use (and may have policies against) external binaries, so they'll mostly want to create their own builds of pdfium (or link against libreoffice's libpdfiumlo.so).
• We do not currently have a mind of adding a more generic way to plug in custom headers/binary/version, either, because it would effectively end up as a file copying shim and a mere wrapper around ctypesgen. Again, we see no sufficient advantage that would justify the new code. (To the contrary, an internal ctypesgen call raises questions how to pass parameters, and which, and would likely end up lacking flexibility.)
• If callers want to do this, they are free to call ctypesgen directly. Matching JSON version info that complies with our conventions will also need to be generated or provided at patch level. Then data files may be copied into src/pypdfium2/ and installed using prepared!. Callers that do desire bundling may also include a binary.
• Offline setup.py is outside the use cases we plan to officially support or provide assistance with, so callers are on their own with it, but we intend to keep it possible on a minimal effort basis using prepared!. (Note, end user offline installation is of course supported with wheels.)

This is the (provisional) decision. Since this has taken already way too much time, and the time I can afford for this project is limited, I do not wish to discuss this further and may lock the relevant threads for now.

Botching in new code for downstream use cases and questioning design decisions is easy, but often not applicable/maintainable for upstream, and time taking and distracting to justify. I did this once and do not wish to do it again.
In the end I'll have to drive this project in the way I see fit, and neither intend to nor am able to please everyone.

[mara004]

FWIW, I added some instructions, anyway: https://github.com/pypdfium2-team/pypdfium2/#install-source-caller

[mara004]

Oh, now https://github.com/NixOS/nixpkgs/pull/268285/files#r1399846307 was a bit of an eye-opener: we could just add caches for tarball and refs, which shouldn't be difficult and might actually be beneficial for the setup logic itself.
For the refs I already had it under consideration for performance reasons anyway.

I plan to work on this when there's time.