On 02 Sep 09:14, simon.klem...@gmail.com wrote: > 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.
This is a wrong goal and will not land in Tryton because:
- it does enforce uniqueness of module name
- it is useless because modules can be registered via pkg_resources.
> 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: !
Simple it sets the right state.
> - 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?
Don't see the lines. (Refering to line numbers is useless if we don't
have the version, so use a link)
It is a oriented graph so yes the childs are named childs.
> - the searching of module-paths happens a few times spread all over trytond
> (modules/__init__, tools/misc,..)
Please show examples.
> - the only reason to introduce a graph and (singleton-) nodes is to have
> pretty-print?
No, look they are methods.
> However, i ended up reverse-engineering
reverse-engineering with the source code :-)
> and rewriting the whole thing and
The best way to not have your contribution accepted.
Why will we accept to maintain your new code instead of existing one?
What are the proofs that your code is better? What does it fix?
By reading your comments, I see more that your code introduced bugs than
fixing.
> 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.
file_open is any way needed by other functionalities.
> 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
So your tree is not the same as the current one so yours is not
compatible.
> 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')
This is not simple thing and you can not explain what you are fixing.
> 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)
For me, the code is understandable but of course there are room for
improvement but not as a big re-write because it is very delicate
subject.
So if you want to improve and contribute, please do it small step by
small step instead of telling us: I don't understand the code so I
rewrote it.
--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/
pgpbkeNEIP_iB.pgp
Description: PGP signature
