Open sbidoul opened 1 month ago
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__)
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).
Also to implement manifestoo list-depends --ignore-core-addons
, etc...
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.
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.
OK. In that case my vote would probably be for the GitHub action, as that seems like the minimal change overall:
manifestoo-core
won't suddenly start making network requests where it previously did nothing.manifestoo-core
so its module list matches that of Odoo itself. A separate "addons repo" makes that more complicated IMO.
master
, which might be much less stable.As to the implementation:
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: