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 :)

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.