On 11/28/2016 05:30 PM, Barry Warsaw wrote: > On Nov 28, 2016, at 11:11 AM, Scott Kitterman wrote: > >> @@ -534,6 +534,13 @@ >> This requirement also applies to extension modules; binaries for all >> the supported Python versions should be included in a single package. >> >> + As a special exception to the `python3-' and `python-' binary naming >> + policy, Python modules intended for use with Django (`python3-django'/ >> + `python-django') should add django to their binary package names to >> + make it clear they are intended for use with Django and not general >> + purpose Python modules, i.e. `python3-django-' and `python-django-' >> + respectively. > > +1 but I have a question since I'm not a hardcore Django developer. > > In many cases we have namespace packages, e.g. zope.*, flufl.*, etc. Usually > these will be called python-<main>.<sub>, e.g. python-flufl.i18n. > > Is there any risk of having confusing names because of a conflict between a > 3rd party Django module and a Django subpackage? e.g. python3-django-foo > vs. python3-django.foo. > > I'm sure it's a non-issue in practice. > > Cheers, > -Barry
Because of problems when doing imports in Python3 (in a venv, the system module wont be loaded if it's there and there's already something in the venv), we should attempt to discourage upstream to use namespaced modules. This indeed could prevent from running unit tests. That's what has been discovered in the OpenStack world, and now all the oslo libs aren't using namespace (though we've kept the dot for the egg-names). Cheers, Thomas Goirand (zigo)
