hi there, first thing, im sorry for doing this in reverse order: i have already opened a codereview at http://codereview.tryton.org/10481002/ and am now writing in here to state my motivation.
the reason i even took a deeper look at modules/__init__.py was that i wanted to run tryton in a more project/framework oriented way: having a project folder with tryton modules and my own modules, similar to how a common django-project would look like. This would ease the process of developing (getting started using sqlite straight away) and creating docker-instances a lot for me. a short draft of how it would look like is at: https://github.com/hiaselhans/tryton-deploy So i started to look into the module-loading and thought it should not be too hard to add more module-directories to it. But reality turned out to be the opposite, because the logic was really hard to understand and very weird at certain points, some examples: - 226-231: ! - 332-333: its really hard to find out what 'childs' are because its strange how they are set/found. second is that once i found out that its actually modules which have the current one as a dependency it seemed really strange that the logic did not apply on extras_depends? - the searching of module-paths happens a few times spread all over trytond (modules/__init__, tools/misc,..) - the only reason to introduce a graph and (singleton-) nodes is to have pretty-print? However, i ended up reverse-engineering and rewriting the whole thing and the result is in the stated codereview... the concept is to have a module-index which crawls all places containing modules on request and can create lists of modules sorted by dependencies. this index holds all the modules and therefore things like file_open became obsolete because the module-path is known all the time. the first approach to create a sorted list was recursive which should have still been valid, but the order was different which broke tests from stock_lot (databases arent dropped and thereby sale was installed already..), thats why in the meantime it is iterative again together with http://codereview.tryton.org/10511002/ even more simplification could apply to it, but excuse me, if i might have been too aggressive resulting from the frustration of being rejected so harsh on such a simple thing... (i still fail to understand the difference between builtin-modules and 'modules') please dont get me wrong, i dont want to reinvent the wheel, but i wonder how this is maintainable if its hardly understandable (it seems like it roots in openerp era) I would be really happy to hear your feedback/concerns/ideas best regards! simon
