This does not help me to understand.
Like I said earlier, I think we have two competing visions for what the goal of the tryton.cfg extension. From my understanding:
- You see sub-folders as a pure file organization tool. In big modules, we end up with big 2k lines (conservative) files. Using sub-folder may help by providing some sort of local namespacing of files (one could have different “wizard.py” files in the same module, provided they are in a different sub-folder). In this context, it indeed makes sense to keep one
viewsfolder, and adding sub-folder there also makes sense - I see them as a feature / depends organization tool. A sub-folder is part of the module, but is a container for something (feature, extras…) auto-sufficient. It contains model extensions (of models declared in the main folder! ) has its own tests, doc, etc… In this context, having views / icons & co in the sub-folder totally makes sense, since it fits the idea of an autonomous part of the main module.
While I understand the pure file approach, the contained feature approach better fits my codebase. I already have features in sub-folders, with their own tests and everything. We have a ir.ui.view override to add a sub_module (sry for the naming) field, so that we also have the views in the sub-folder. We also have “extras_depend” themed sub-folders. We are slowly migrating existing big features / extras this way, with this idea of autonomous folders.
My point is, as someone with a big module codebase, the fully separate sub-folder has more value than the file-only solution.
In this case it can be a module.
It could, but it does not have to be. We find that we have too many modules to make them understandable by our internal users. This is due to historical reasons (when extras_depend did not exist as it is today) and to the cost of merging modules.
Let’s use a concrete example: We have a api module, and many modules have it as an extras_depend. Ideally, I would have a separate folder in those, with dedicated tests & co. I do not want to create a “xxx_api” module for each case.
Same with a reporting module.
I am using technical modules here, but we have the same structure with “business” modules. Let’s say I am installing a “loan” module to manage loan contracts, it will have to adapt the models for all our business features depending on whether they are activated or not. The __init__.py for this module currently has over 20 call to Pool.register(..., type_="model"), to account for extras_depend combinations. I’d want to have most of those in separate sub-folders, not create 20 extra “glueing” modules.
This are not “auto-sufficient”. This is exactly the case where a sub-folder fits.
I can not say for that. But I could imagine that it would make sense to have loan_construction, loan_consomption etc. I do not think it will be complicated to understand.
Moreover having sub-folder vs specialized modules do not remove the complexity of finding the right place for a feature.
I do not think that when it is adapting a main module to a specific business, it cannot be called “glue module”.