Download core addons list at runtime

[sbidoul]

Currently, the list of Odoo CE and EE core addons is part of the code, and must be updated regularly, which is a burden.

Alternatively, we could consider downloading this information at runtime.

A few thoughts:

• can this be done without changing the public API ?
• while the list of CE addons is accessible publicly from the https://github.com/odoo/odoo, Odoo EE is not
• obtaining the information from git would likely be too slow
• so pre-cooked files should be made available somewhere (here on GitHub? as releases? or in the wiki? or serve it via github.io? or elsewhere?)
• and local caching would be necessary anyway for performance / off-line operation
• need to determine local cache invalidation mechanism (frequency? how to force it manually?)
• generating these files manually would be an improvement, since it would not require a manifestoo-core release, but still a burden
• generating these files automatically requires some infrastructure (a scheduled GitHub action here?)
• generating these files require a user or GitHub token that access to https://github.com/odoo/enterprise

[aisopuro]

To clarify for me, is it necessary for manifestoo-core to know the core/enterprise addons even in contexts where these are not installed?

I.e. does it have to have a static list to compare with? Could it not simply do something like (not exactly this but hopefully my meaning is clear):

@lru_cache()
def _get_core_addons(odoo_series: OdooSeries, odoo_edition: OdooEdition) -> Set[str]:
    from odoo import addons
    return as_list_of_strings(addons.__path__)

[sbidoul]

Yes it's a necessary feature of the lib. For instance whool needs it to know it to know if a depends in an addon manifest needs to translate to odoo-addon-... or odoo (for core addons).

[sbidoul]

Also to implement manifestoo list-depends --ignore-core-addons, etc...

[aisopuro]

I see. Could we mitigate this issue by having both? If manifestoo detects an installed odoo/enterprise, it would pull the addons lists from there, otherwise it would fall back to either the current system or possibly a network request like you suggested.

My use case is that we are packaging Odoo inside a docker image, alongside some generally useful addons. In my use case I would prefer manifestoo-core to exactly know what is available: for example if I somehow end up trying to install an old version of Odoo core, but a new version of enterprise, I would want the build to fail since enterprise is missing a dependency l10n_ng, which my outdated core doesn't include.

[sbidoul]

Could we mitigate this issue by having both? If manifestoo detects an installed odoo/enterprise, it would pull the addons lists from there, otherwise it would fall back to either the current system or possibly a network request like you suggested.

I don't think that's possible

But in your case, if you know the directories where Odoo CE and EE addons are located, you could use something like manifestoo --select-addon-dir=./odoo/addons --select-addon-dir=./enterprise list and/or list-depends and script your way from these.

[aisopuro]

OK. In that case my vote would probably be for the GitHub action, as that seems like the minimal change overall:

• Basically the same thing that has already been happening, but automated.
• manifestoo-core won't suddenly start making network requests where it previously did nothing.
• I feel like "check from a static file that is in the code at this version you are running" is still clearer than "check from a non-static file somewhere else on the internet"
• A weird case, but I don't know that I trust Odoo to not add a module one day and then immediately remove it the next. For those cases it could be nice to be able to pin manifestoo-core so its module list matches that of Odoo itself. A separate "addons repo" makes that more complicated IMO.
  • This might also be relevant if someone wanted to install Odoo core from master, which might be much less stable.

As to the implementation:

• I think GitHub actions can probably be given secrets? This is at least possible in GitLab, so I hope it works here as well.
• You will probably want to restrict that job to only run on schedule against the main branch, not on PRs. So that malicious contributors can't misuse the secret.
• The update script should perhaps be changed somehow to not bake the dates into the file, or at least to bake less of them. That way the job can make a new updated file, compare with the previous one, and only once there are actual changes would it update the file and make a new release.