generator of dependencies

[hparfr]

Hi,

At Akretion, for managing dependencies we use git-aggregator + ak.

ak wraps git aggregator and offer a easier interface for users (len(ak) < len(git-aggregator) ), shorter syntax.
It's adding tree more advantages:

• it have a modules keys
• it create symbolic links to have a simple addons_path
• it does git sparse-checkout (with the module list) to reduce the size of the docker image, and the load of the IDE for LSP, fuzzy-search... and reduce human errors (edit a copy ot the file)

For the moment, I'm able to generate a "spec.yaml" with its requirements.txt. Only with stable / published modules.
It works also with migrations. For instance on a 16.0 project, I can generate the result of the migration path in 18.0 (only the merged modules).

In the future, I plan to be able to scan a spec.yaml of a project, forks and PR included and be able to generate it back.

When I experimented with pip (we use it rarely) I discovered when you start to use forks and pr the manual list can be very boring to build and maintain.

Few years ago you were using git-aggregator with git submodules at C2C. Is it still a thing ?

So I have this basic module yet tied on ak. I can let it leave in my "specific" projet. Or does it make sense to publish it here.
And about the design, I can make it more reusable to add other outputs like pip or vanilla git-aggregator if you intend to use it.
@sebalix

For instance, I asked the spec of account_invoice_facturx.
I get the dependencies, account_payment_method_base, *_unece, and mandatory modules of all akretion projects: auth_oidc_akretion_data, database_age_cron, and its dependencies (auth_oidc_environment...)

[sebalix]

Hello @hparfr ,

Yes we are still using submodules with git-aggregator (vanilla config files but with C2C frontend commands to rebuild/push/check consolidated branches).
Still, we are using it only if we have pending merges, for modules/features already available in upstream repo, there is no use of git-aggregator.
We wanted to switch to pip at one point, but don't know where we stand regarding this yet.

Also, odoo-repository was initially designed to work first on any kind of projects (Odoo SaaS, Odoo.sh, custom hosted ones...), so I didn't work on that topic but it's something I had in mind like you!

So yes, such a module has its place for sure, I don't know how complex it can be to be agnostic regarding the build system. Do as you wish I would say, if it's too much work on your side, no rush :)