Web2py-3.x compatibility

[nursix]

This PR adapts Eden to web2py-3.1.1, while retaining web2py-2.27.1 compatibility - so it can be run with both versions.

However, it does not yet list web2py-3.1.1 as supported version because that version (or actually, the PyDAL version it comes with) still has some issues itself, which would need to be fixed upstream or patched locally before we can claim full support.

Further, this still needs to be tested on Python-3.13 (so far only tested on Python-3.11) - so it is not ready for release just yet - but still a critical step into that direction.

For testing (only partially done, Python-3.13 still untested):

• add "3.1.1" to the supported web2py versions locally (in modules/updatechk.py - check_web2py_version)
• remove the models/0000_update_check.py file
• pull your local web2py install, reset it to commit d6dcbef, and update all submodules
• run the local instance on Python-3.13 if available

For backwards-compatibility testing (passed/complete, but re-testing welcome):

• reset web2py to commit 49bb23c and update all submodules
• drop the models/0000_update_check.py file again
• run the local instance on Python-3.11

Thank you!

[nursix]

Here is a patch for PyDAL-20251207.1:
pydal.diff.txt

This patch fixes an inconsistency in the IS_EMPTY_OR logic of default validators - which is the one breaking issue that currently prevents us from moving to web2py-3.1.1. See also web2py/pydal#752

[nursix]

Upstream PR submitted here: web2py/pydal#755

[awjans]

This looks very clean.

[awjans]

NIT: Should we rename 'table_user' in this method to 'utable' for consistency?

[nursix]

I don't think so - table_user is a hint that this uses auth.settings.table_user rather than s3db.auth_user (for which utable would typically be used).

Of course, right now both point to the same database table - but the origin of the reference is different.

[awjans]

OK, that makes sense.

[nursix]

So, that said, it would seem more consistent to rename utable in login_bare (above) to table_user to indicate the fixed origin of the reference.

There is a subtle difference between the two: auth.settings.table_user is a Table (or None), whereas s3db.auth_user returns a Table (or raises). Within AuthS3, self.settings shall be used to access the tables from self.define_tables, not s3db - to ensure the tables belong to the instance (and cannot be manipulated outside of it).

[nursix]

...but even though I agree that there is some inconsistency in variable naming here: this is unrelated to the subject of the PR. So I'd say let's test this for its purpose and fix the naming inconsistency later.