> Hi folks, > > You'll probably say we don't communicate enough our intents... anyway, better > late than never ;-)
That's true, but you should communicate "intents" not "things you've already done" :P > We plan to package our addons the way the Python community is accustomed to. That's a great news! :) > There are two options: > > - each addons has its own namespace, e.g. openerpsale, openerp_sale. When > another addons want to depend on `sale`, it can import openerpsale or import > openerp_sale. This is a clean option. > > - a somewhat less clean option because it relies on some extra work (e.g. > pkgutil) (and is probably quite debatable), is to use a shared namespace. > We've decided to use that one, partly because it provides a smoother > transition path (we have to be backward compatible for some time). More > specificaly, we want to use the openerp.addons namespace. Addons can still be > packaged separately but will be imported as, say, import openerp.addons.sale. I'll take the Plone world as an example once again. All the core packages are in the "plone.*" namespace (the plone-only specific packages use double namespaces "plone.app.*", see https://github.com/plone). The ones from the community fall in the "collective.*" namespace (see https://github.com/collective). Of course, no one prohibit to have your own namespace such as "mycompany.*". So, we can use "openerp.*" for core packages (like "openerp.res") and "openerpcommunity.*" for community addons. Bests, Simo -- https://code.launchpad.net/~openerp-community/openerp/skitzotek_trunk_symlinks/+merge/93115 Your team OpenERP Community is subscribed to branch lp:~openerp-community/openerp/skitzotek_trunk_symlinks. _______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
