[IMP] Move SUPERUSER_ID to odoo.api

[kmagusiak]

Description of the issue/feature this PR addresses:
Move odoo.SUPERUSER_ID to odoo.api.SUPERUSER_ID.
In order to become a namespace package, odoo package should not contain any variables, only modules.

odoo/enterprise#71223
odoo/upgrade#6585
odoo/upgrade-util#144
task-4069446

---

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

[robodoo]

[kmagusiak]

PR is rebased and ready.

@odoo/rd-security The security warning in __getattr__ of the init file. The goal is to load and show a warning when using variables directly defined in odoo module. The module and name are whitelisted at the beginning of the function in the match statement.

[Julien00859]

The day we make odoo a pure package, we'll no longer be able to import odoo and then use odoo.something unless odoo.something is imported. It means that one day odoo.api.SUPERUSER_ID is going to break unless import odoo.api.

We can decide to postpone the problem to later, we'll have MANY files to update in the future anyway.

[kmagusiak]

The day we make odoo a pure package, we'll no longer be able to import odoo and then use odoo.something unless odoo.something is imported. It means that one day odoo.api.SUPERUSER_ID is going to break unless import odoo.api.

We can decide to postpone the problem to later, we'll have MANY files to update in the future anyway.

I have made changes according to your comments.

If the module is loaded it won't fail. So if you do this in an addon, odoo.api will be imported before the execution of the module.
I started a PR in which I'm no longer importing a lot of modules during import odoo and fixes such bare imports: #185330.

[rco-odoo]

Can we please slow down a bit, and take a step back?
What I see coming will make the use of odoo more painful for developers for, and the added value is purely technical. As Odoo developers, we clearly are losing value.
The real problem is not odoo, it's odoo.addons, isn't it?
This really feels like the wrong solution to me.

[kmagusiak]

odoo and odoo.addons are now legacy namespace packages which are not supported by all tooling. Removing the __init__.py makes a package a native namespace package. PEP-420.
If we keep the init file in odoo and remove the one from odoo.addons, it will run, still it won't be seen correcly by tooling because odoo is not a native namespace.

Removing the init means we need to do declare these variables elsewhere. Without an init, the order of loading sub-packages of odoo is no longer controlled (not an issue if package dependencies are correct).
/~https://github.com/odoo-dev/odoo/commits/master-packaging-poc-pep420-krma/ - is a POC where variables odoo.XXX are set by another package. However, if you try to from odoo import XXX before that other package is loaded, you will get an error. In any case, you won't have typing information at all since these variables are not declared.

(task-4035335 for more details)

[rco-odoo]

odoo and odoo.addons are now legacy namespace packages which are not supported by all tooling. Removing the __init__.py makes a package a native namespace package. PEP-420. If we keep the init file in odoo and remove the one from odoo.addons, it will run, still it won't be seen correcly by tooling because odoo is not a native namespace.

Here is the problem that we are trying to solve: we want the addons to be in a native namespace package. This would enable any decent IDE to figure out what from odoo.addons import X actually refers to.

I think that making odoo itself a native namespace package is nonsense, because it was never meant to be like that. This screws up all the imports we are used to do, for completely artificial reasons. And it simply doesn't make sense at the odoo level: you wouldn't distribute odoo.models without odoo.fields, would you?

Can't we find a better solution? What about making odoo_addons an actual namespace package, and simply make odoo.addons a simple alias to it? This would give you the benefits of resolving imports without the artificial changes, wouldn't it? My point here is to challenge the chosen solution, which I find bad.

Removing the init means we need to do declare these variables elsewhere. Without an init, the order of loading sub-packages of odoo is no longer controlled (not an issue if package dependencies are correct). /~https://github.com/odoo-dev/odoo/commits/master-packaging-poc-pep420-krma/ - is a POC where variables odoo.XXX are set by another package. However, if you try to from odoo import XXX before that other package is loaded, you will get an error. In any case, you won't have typing information at all since these variables are not declared.

I am sorry, but all this is about a non-existing problem. The module odoo itself is not perfect, but it's fine.

[kmagusiak]

Here is the problem that we are trying to solve: we want the addons to be in a native namespace package. This would enable any decent IDE to figure out what from odoo.addons import X actually refers to.

The thing is that any decent IDE cannot figure out that odoo.addons is a native namespace if odoo is not a native namespace.
I have explored some alternative solutions and all of them required to move a lot of files and/or change nearly all imports in the repository, that's why I did not pursue further things like odoo_addons (for example vscode does not detect odoo.addons... once you put import odoo_addons as addons in the init of odoo).