Re: Binary naming for Django Related Packages
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)
Reply to: