Re: Binary naming for Django Related Packages
On Tuesday, November 29, 2016 02:40:06 PM Piotr Ożarowski wrote: > [Scott Kitterman, 2016-11-29] > > > 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? > > if module name is foo, name of the binary package should be python3-foo, > not python3-bar-foo. There is no change needed on the upstream side or > in django/__init__.py - it's just about naming binary packages the way > our policy recommends. Adjusting policy to document good changes we came > up in practice is good. Documenting bad ones is not. > > That said, I don't have a veto vote so I will just have to deal with it. I can see your point. I can see Raphael's too. I do think that upstream third parties using django_foo represents some kind of best practice that should be documented and encouraged (but not directly by Debian). Raphael, do you think that the upstream Django project might be willing to make some kind of best practices for naming third party django packages? If they did that, then that would give us a basis for Debian maintainers talking to their upstreams about moving to django_. Over time, that would result in python-django-foo being the correct name without any kind of Python policy exception (and we'd limit this to being temporary). How's that? Scott K
Re: Binary naming for Django Related Packages
[Scott Kitterman, 2016-11-29] > 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? if module name is foo, name of the binary package should be python3-foo, not python3-bar-foo. There is no change needed on the upstream side or in django/__init__.py - it's just about naming binary packages the way our policy recommends. Adjusting policy to document good changes we came up in practice is good. Documenting bad ones is not. That said, I don't have a veto vote so I will just have to deal with it. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Binary naming for Django Related Packages
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
Re: Binary naming for Django Related Packages
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/
Re: Binary naming for Django Related Packages
On Mon, 28 Nov 2016, Piotr Ożarowski wrote: > [Barry Warsaw, 2016-11-28] > > 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. > > this is a huge issue IMHO beacause Django submodules use global > namespace and thus any unique django submodule name takes not so unique > Python module name (i.e. they're installed under > /usr/lib/python3/dist-packages/ now, not under > /usr/lib/python3/dist-packages/django) This is true but it's still a non-issue in practice because that kind of conflict is usually detected and thus avoided at the pypi level. And checking for file conflict is part of the job of the packager and we have QA tools doing that kind of work too. 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/
