On Tuesday, November 29, 2016 01:52:07 PM Raphael Hertzog wrote:
> 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).

Thanks for the feedback.  I think that eliminates Piotr's options 2.

Personally, I think policy is at its best documenting current practice rather 
than to drive it, that's why I made the initial proposal.  There's an 
exception to the usual rule that is virtually universally applied, so I 
believe we ought to document it.

Piotr: Is there some language that acknowledges the situation as unusual, even 
if it doesn't fully bless it that you'd be comfortable with in policy so we 
can at least document current practice?

Scott K

Reply via email to