On 05/04/2011 06:25 PM, "Cédric Krier" <[email protected]>" wrote: > Hi, > > The recent upload of packages from pjstevns on PyPI [1] shed some ligth on a > potential issue. > For now, we use a schema for naming the packages of Tryton modules which is: > > trytond_%(module_name)s > > But we have no guarantee that this name will be available for new modules in > the future because we don't have control on PyPI. > > Of course, we can rely on a good collaboration of people but there is no > guarantee. > I see two options right now: > > - changing the name of the package for modules that will be taken by > someone else. But this means that in the setup.py we can no more rely on > the package naming to generate the dependencies.
I'm not sure I understand what you mean. There is currently a flat namespace below trytond.modules.<MODULENAME> Either a module name is taken or not. You might be using a different module under the same name, but only if you mix sources. Another option would be namespace overloading, though a tradeoff would be implied: If tryton would support proper namespace packages, we might also use module sub-namespaces: trytond.modules.contract trytond.modules.my.contract Loading of modules should then not be automatic, but by configuration. Each has it's pros and cons. > - create our own instance of PyPI (on pypi.tryton.org) like that we have > the control over the package naming. But this mean that we need to > maintain the services and also user need to specify the Tryton index in > the installation command line like: > > ``` > pip install -i http://pypi.tryton.org/simple \ > --extra-index-url=http://pypi.python.org/simple \ > PACKAGE_NAMES... > ``` > > Of course it can be setup in the configuration file. Running your own package repo will help. And integrators can mix your repo with their own to over-ride with customized packages if they choose to do so. Specifying index urls is completely trivial for scripted deployments like buildout anyway. > PS: @pjstevns of course it is not against you, it is general issue you was > just the revealer. And your modules will be welcome in the mainstream after > some codereview ;-) No worries. Pypi is just a great way to create some noise. Whatever works best suits me - though I really like my current workflow with git(hub). However, moving packages to hg.tryton.org won't solve any of this. > [1] http://pypi.python.org/pypi/trytond_timesheet_invoice/2.0.1 > http://pypi.python.org/pypi/trytond_contract/2.0.1 > http://pypi.python.org/pypi/trytond_account_nl/2.0.1 account_nl should be ok to include in the core set. contract and timesheet_invoice work-for-me, but they will be not quite as generic (bland?) as is the custom in tryton. contract is aimed at periodic invoicing of services. No stock transactions are involved, though that might easily become a requirement. timesheet_invoice works really well for me. It allows me to keep track of hours spent on tasks, and generate invoices from those. Must be useful for more people, I'm certain! Only diversion from tryton custom is that I don't use UNO/relatorio for reporting. I use reportlab-rml driven by zope page-templates to generate PDF rather than ODT. I left the NFG logo in the example timesheet report which will be removed. Using macros in the base-template that can overriden/provided from a localization module will be in a future version. But maybe that is for another discussion :-) -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl -- [email protected] mailing list
