Shim SILE.types

[Omikhleia]

See sile-typesetter/sile#2053 (comment)

• Add a silex.types compatibility layer (see below SILE.types scoped objects in SILE), as we had done in advance for SU.ast
• Make a silex.sile minor release
• Go one by one on each of our xxx.sile module to upgrade their code
  - List here below each module as analyzed, fixed and released
  - Non-affected modules: couyards.sile, labelrefs.sile, smartquotes.sile, spreadsheet.sile
• Perform non-regression testing with SILE 0.14 (expecting no issue)

So the 0.14-based workflow of my current book projects still works but all modules are prepared for 0.15 (and we'll need testing them with 0.15 but the code should already have been updated -- and we'll have that part behind us if any problem occurs).

Food for though (from @alerque 's script):

s#\bSILE.color\b#SILE.types.color#g
s#\bSILE.colorparser\b#SILE.types.color#g
s#\bSILE.length\b#SILE.types.length#g
s#\bSILE.measurement\b#SILE.types.measurement#g
s#\bSILE.nodefactory\b#SILE.types.node#g
s#\bSILE.units\b#SILE.types.unit#g

I don't think my code base uses those below (as far as I remember), but also to check:

s#\bSILE.paperSizeParser\b#SILE.papersize#g
s#\balignright\b#raggedleft#g

[Omikhleia]

It's a lot of work for something that does not bring better typography, and is not even perfect.

I could simplify my workflow a lot by removing all my .sile modules from the SILE ecosystem, and bring them all back under the umbrella of the resilient collection.

[Omikhleia]

Stuck at markdown.sile and resilient.sile:
Hitting a problem on inputters caused by sile-typesetter/sile#2095 (might be due to our own fork of the base class too - it worked with 0.15.4 but now fails with 0.15.5, some investigation needed)

[alerque]

Yes, you won't be able to use classes that are not based on SILE's base class and don't do the same things it does. You'll have to add the line I added to SILE's base class to the forked one and set SILE.documentState.documentClass = self there, or change a fork of the inputter:classInit() function to check whether SILE.documentState.documentClass got set by the constructor, and if not set it to the return value of the constructor.

[alerque]

I really don't understand why you're using a full fork of the base class instead of creating a new base class and just replacing the functions you want to change. You have exactly the same function class:_post_init as SILE's base (except of course now it doesn't have the necessary changes).

If deriving a new class from base isn't viable I'd like to understand why ... but even in that case you could still set individual functions from it like class._post_init = SILE.classes.base._post_init so as not to have duplicated code at all. That would also allow this particular hickup to work just fine in whatever version of SILE it was run under since it would just use the appropriate function from each.

[Omikhleia]

@alerque Yep, I'm on the issue (though this won't be tonight, it's getting late :) I was just linking the change above so I could investigate the impacts here.

Confirming it works if I revert inputters/base.lua to 0.15.4, but the best "quick" solution would of course rather be to update my silex/classes/base.lua correctly.
The "fork" contains other things at various points, such as early implementations for 0.14 of things that only made it in 0.15, and other features).
As for your remark on rather creating a new base class, it's quite tricky... This stuff has to still support 0.14 for a while (for my current book production workflow), to work with and without resilient extensions, and to support my (unreleased) experimental typesetters so I can go on hacking these "deeply" (without certainty they'll come to light)... Too many games at the same time here... The approach is far from perfect, but I am not convinced another path would really have been easier eventually. When I give up compatibility with 0.14, then many old shims will be removed and maybe the situation can get cleaner. A plain fork is also easier to diff and propose backports to SILE (typically that was the case for the page full bleed stuff, and some of the outputter refactors and fixes).

[Omikhleia]

"Dev" versions of affected modules all merged and updated if need be on luarocks.
Fresh SILE 0.15.5 setup with all dev modules:

• All module examples
• Djot/Markdown manual
• Resilient manual - Noting several pagination differences see comment below
• Awesome SILE books
  •  lovecraft
  • dragon-de-brume-5
  • dragon-de-brume-6
  • LSG - Noting some pagination differences

Regarding pagination differences:

• Some might be differences in rounding...
• Some are expected, due to SIL space handling change (for the better). I fixed a few for the resilient manual, in passing.

This is not unacceptable, and thus next step will be to check my 0.14 workflow still works identically.

[Omikhleia]

Special SILE 0.14.11 (modified, with C code changes for SILE PR 1792 etc. = preceding production workflow), with all my modules on latest dev:

• Djot/Markdown manual
• Resilient manual
• Awesome SILE books
  •  lovecraft
  • dragon-de-brume-5
  • dragon-de-brume-6

Note on pagination discrepancies: on the Resilient manual at least some are the same as observed in Omikhleia/resilient.sile#70 (comment) (= when checking output from Lua 5.4 vs. LuaJIT + possibly having some fonts in different versions due to when the docker base image was built)

[Omikhleia]

All tasks done, all modules tagged and uploaded to luarocks, Yay!

[Omikhleia]

Doh, forgot one thing... :(
Some of the standalone modules rockspecs weren't updated for the new version of their dependencies.
That could mostly be a problem for people updating them and still see deprecation warnings on those dependencies. Oh well, at least resilient.sile has all of them right, and installing it forces all other modules correctly...