PROPOSAL: One Repo - One Module

[blaggacao]

For many, the actual layout of the OCA repositories is a headache. I'm sure there have been good reasons at the time of decision making to choose this layout, but I want to challenge them for the better.

The benefits of a "one repo - one module" structure:

• simpler responsibility attribution (more fine grained maintainers)
• much easier git flow handling
• attribuible github issue tracking

However, it is NOT a question of weather one or the other!!! Best of both worlds would be obtained by: github.com/oca-dev with a "one-module - one repo" logic github.com/oca with a project logic using git submodules

the git submodules approach adds the benefit that the PSC can do a more efficient work by using curated commits for each submodule individually in the github.com/oca repo.

[dreispt]

the git submodules approach adds the benefit that the PSC can do a more efficient work by using curated commits for each submodule individually in the github.com/oca repo.

Unless I'm getting it wrong, that sounds like a lot of additional administrative work for the PSC.

[nhomar]

SUPE :-1:

Too much work to administer/test/deploy.

It has been discussed already an dwe are not prepared yet for such deal.

[blaggacao]

@dreispt Well, let's have a closer look (we use submodules extensively): The command works like this: git submodule add git@github.com:oca-dev/foo-repo foo-folder This creates a file .gitmodules:

cat .gitmodules
[submodule "foo-repo"]
path = foo-folder
url = git@github.com:oca-dev/foo-repo

git submodule init && git submodule update pulls everything.

git commit -m "Add submodules a." gives a very clean aggregated history, by specifying the specific commit each submodule will be pulled at.

Fetching the whole repo for deployment: git clone github.com/oca/super.git && git submodule init && git submodule update

@nhomar would you help to point me to that detailed discussion to understand better the arguments, I doubt (it's a firm belive), that it would not be possible to make this a pareto-efficient proposal ("everyone only wins").

My argument is based mainly on the experience, that the actual set up is really difficult to manage as a contributor, because you always have this overhead, that has nothing to do with your actual development...

We have experienced submodules as quite easy, actually.

[blaggacao]

In deployment we circumvent with git sparse-checkout are there any better techniques to prevent some modules from deployment instances?

[dreispt]

I use subdirectories for repos (as git submodules) and the expose modules with symbolic links. You have the extra complication of using submodules, but it works well. You might also try the new pip-installable module distribution.

[max3903]

@blaggacao You can install only the modules you need using packages: http://wheelhouse.odoo-community.org/

[blaggacao]

@dreispt that's an interesting option. Just to note from my docker perspective: this might not work, as symlinks are to be said to pose problems. (Also we wouldn't want to waste on disk space for unneeded code) I'll look for the pip-installable option, never have heard of it. (I wasn't aware of your work on this) @max3903 nice, wasn't aware either. As a sidenote, deploying with docker we would be eager to only ship python bytecode which could reduce image size (especially for pip installs as they iirc compile at build time) by around 40% or more. It's a while already that I'm looking for a binary only pip install. Have you ever heard if something like that?, well a cleanup command does it as well, but It's a bit lowlevel to mess around deliberately.