More docs?

[yajo]

Hey there, I was looking on how to use this, but there are absolutely no docs... Would you mind adding at least something basic?

[sbidoul]

Yep yep, that will come before November.

[sbidoul]

@yajo I added some basic info in the README. More to come in the coming weeks.

[yajo]

Hey, thanks a lot!

I've been reviewing it and I have a couple of questions:

https://github.com/sbidoul/whool/blob/f071acd8dd556499e1a2a818f2b9de0ad9ae09af/README.md?plain=1#L30-L31 https://github.com/sbidoul/whool/blob/f071acd8dd556499e1a2a818f2b9de0ad9ae09af/README.md?plain=1#L38-L39

What happens if I download the addon source as a tarball (surely it will happen for me), if someone downloads sources with --depth=1 (will happen all the time), or if somebody wants to use an alternate VCS such as Mercurial or Pijul (probably won't happen for me)?

Note Going a bit off-topic.

Regarding dynamic version maintenance, I've been using commitizen for about a year and it's very pleasing:

• It can enforce a particular commit format (configurable; defaults to conventional commits)
• Then it can parse the commit history to generate
  • Version bumps. It writes pyproject.toml automatically.
  • Changelogs. It writes CHANGELOG.md automatically.

The benefits of this approach:

• Project source code contains statically accurate info: the version and changelog.
• That info doesn't depend on having to download Git history.
• All you have to care about is committing properly.
  • There's the cz c command to help you on that.
• Less logic needs to be bundled in build tools such as whool.
• Builds can be reproducible in a pure environment such as Nix.

[sbidoul]

What happens if I download the addon source as a tarball (surely it will happen for me),

If it's a proper sdist (with a PKG-INFO file, as generated by pipx run build -s), then it includes all the files in the addon directory

Otherwise, if git ls-files does not work for any reason, it fails. That was a protection measure to protect against older pip versions that did not build in place (we need to correct directory name to get the addon name). We can probably remove this protection now. There is a TODO in the code about that.

if someone downloads sources with --depth=1

I think you'll get the manifest version with an incorrect commit count since last manifest version change in the 6th digit. You can also disable that versioning behaviour with the post version strategy override option.

if somebody wants to use an alternate VCS such as Mercurial or Pijul

Other VCS are not supported ATM. PRs welcome (the file selection logic is here, and the versioning logic is in manifestoo-core).

I've been using commitizen

Thanks for the tip. I had heard about it but never looked in detail. I'll put that on my list of things to investigate. Does not sound trivial to apply to OCA, though, but worth investigating nevertheless.

[oyale]

Hi!

In the current docs, there is a mention about multi-addon projects, but in the hatch-odoo README there is a notice:

💡 This project is best used when working with end-customer projects. To package individual reusable addons, consider the whool project.

So, what would be the tool to replace the setuptools-odoo-make-default -d . command, which would create the individual config file for each addon in a repository, allowing to reuse them individually?

I assumed that the answer was whool, and after run pipx run whool -h, I read the subdirectory part.

This is done in the current directory if it is an addon, else in immediate subdirectories
                 that are addons.

So I just ran pipx run whool init and all worked like a charm!

Maybe it's worth clarifying it on README?

---

I've been using commitizen

Thanks for the tip. I had heard about it but never looked in detail. I'll put that on my list of things to investigate. Does not sound trivial to apply to OCA, though, but worth investigating nevertheless.

Regarding adapting commitizen for OCA workflows, we did some exploration on this in the past:

https://git.coopdevs.org/coopdevs/tooling/commitizen-oca

[sbidoul]

@oyale thanks for the valuable feedback. I improved the README in 9f2e080ddcbbea0e157043decf2528c11461a181.

[Lionel-cl]

Hi, What you are doing is awesome! But indeed a complete example will be very useful. And even better it would be to have a little tutorial.

To start: can you tell us an OCA repo that uses this new approach? This would be a good example of achievement. Thanks

[sbidoul]

@Lionel-cl thanks. Have you had a look at the README recently, specifically the Quick start section ? What's missing in the docs, IMO, concerns advanced use cases that are very rarely useful with recent Odoo versions anyway.

Otherwise, all 17.0 branches in OCA have a pyproject.toml in each addon.

[Lionel-cl]

@sbidoul Thank you for your answer. Yes I read the readme but it is not that clear to me. I just saw that this work was an extension of Hatch https://hatch.pypa.io/. So I'm going to start by reading this doc. An introduction with cross-references could be useful for those like me who land directly on your repo. My questions are:

• what should be installed?
• what are the commands to run to install such a "super" module on my odoo instance ?
• how can I create a "super" module with sub-modules? A lot of the answers should be in this Hatch doc. I will then come back to your tool.

I'm currently using odoo 16 and haven't looked at 17.0 branches in OCA yet.

[sbidoul]

Ah, I see. You are probably looking for hatch-odoo instead of this project. I added a note at the top of the README.