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
> [2]. 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/
