Use zimscraperlib (in place of zimwriterfs) + upgrade to Python 3.11 + dependencies

[benoit74]

Fix #136 Fix #156

[benoit74]

Some questions / remarks:

• some CLI flags have been removed because they do not makes anymore sense
• I did not achieved to find if it is still possible to create a ZIM without index with zimscraperlib
• I did not achieved to find the documentation regarding the standard minimal Python code guideline (black + isort + flake with 88 chars max length if I did it appropriately in iFixit)
• I did a smoke test with few random books, do you have any idea of which book IDs are particularly relevant to test because they represent a corner case?

[kelson42]

• I did not achieved to find the documentation regarding the standard minimal Python code guideline (black + isort + flake with 88 chars max length if I did it appropriately in iFixit)

It’s here https://github.com/openzim/overview/wiki but clearly not complete.

[benoit74]

Thank you for all these comments, I will work on it later this week, seems pretty easy to fix.

[benoit74]

@rgaudin, I fixed all inline comments except the one regarding the SQL timeout, see proposition above.

I also fixed following issues (well spotted 👏):

• the language information passed to export_books that gets transformed for ZIM metadata
• links also include namespace prefixes that should be removed

I don't achieve to reproduce this issue (could you provide more info?):

• links are broken ; pointing to out-of-bound level (tools.js)

Regarding the link to the PDF which should not be displayed, I confirm this seems not linked to current PR. Issue is present in many places: cover article (gutenbergtozim/templates/cover_article.html), HTML version of a book (gutenbergtozim/templates/book_infobox.html) and bookshelves (2 times in gutenbergtozim/templates/js/tools.js).

[kelson42]

@benoit74 Any chance to fix the CodeFactor issues? Usually the only one which are tolerated are the "complex method" ones (which would need a massive revamping and often are older than the PR itself).

[rgaudin]

@benoit74 Any chance to fix the CodeFactor issues? Usually the only one which are tolerated are the "complex method" ones (which would need a massive revamping and often are older than the PR itself).

@kelson42 the codefactor issues are from the legacy code. They show up now because the file was touched (to fix the links) but were not introduced now.

[benoit74]

@benoit74 Any chance to fix the CodeFactor issues? Usually the only one which are tolerated are the "complex method" ones (which would need a massive revamping and often are older than the PR itself).

@kelson42 the codefactor issues are from the legacy code. They show up now because the file was touched (to fix the links) but were not introduced now.

Yep, I opened an issue to fix this, I would clearly prefer to have this PR merged first. This PR has changed many parts of the code, so delaying it too much is taking a risk of merge conflicts later. And I'm clearly not an expert in JS code, and this tools.js script seems a bit scary to fix without spending some time to understand all its purpose and confirm it is still working as expected afterwards.

[rgaudin]

Good to merge ;I'll do it tomorrow; thanks

[benoit74]

BTW, I also opened this issue as discussed: https://github.com/openzim/gutenberg/issues/159

[benoit74]

Good to merge ;I'll do it tomorrow; thanks

I can do it if you prefer, @kelson42 granted me sufficient rights. Do you mind if I squash all commits? Are you ok with fast-forward merges? (these are my preferences, but I clearly don't mind to follow other conventions)

[rgaudin]

Please do. Our convention is to use a merge commit though