On Mon, 28 Nov 2016, Scott Kitterman wrote: > > > Please let me know what you think. I'm open to suggestions on wording. > > > I'd like to get this done in the next week and do a python-defaults > > > upload with this and a few minor (non-policy) changes that are pending.
+1 from me. I'm actually the one who started this convention when I packaged the first Django extension. When I look for available Django extension, I like to be able to rely on the prefix. > > [²] sys.path.append('/usr/lib/python3/django-packages/') in > > django/__init__.py if django import always prepends other imports > > (python3-django- namespace would be tolerable then, I guess) > > I'm not one of the python-django uploaders, so we'd need their feedback on > . I think something like that is a reasonable compromise if they are > willing to support it. I certainly don't want to introduce this Debian-specific difference, no. Django applications/extensions are meant to be managed via "pip" and they must be available in the global namespace. I would not be surprised that some of the extensions actually rely on being available globally... I don't see any benefit to this change. The global namespace pollution already exists at the upstream level, while we have to handle potential conflicts, it's not up to us to preventively curate the namespace when upstream has not followed the best practice (i.e. the "django_" prefix in the module name). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/