Binary naming for Django Related Packages
I've recently done some Django related packaging for the first time and noticed that we have organically (as far as I can tell) grown a slightly different naming convention for such packages. Instead of python*-foo, we use python*-django-foo. I think this is a reasonable approach and followed it in the new packages I've recently done. I decided to check and see how common the approach is. Here's what I found in Sid: Start with django: 7 Start w/django, not transitional: 2 Start with django3: 0 Start with python-django (excluding -doc): 136 Start with python3-django: 84 I think it would make sense to add this to the Python policy so how we're doing it is documented. I am attaching a proposed diff. I made it a should because there are two non-DPMT packages that don't follow this rule and I think it's late in the cycle to be adding to must policy requirements. 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. Scott K @@ -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. + signature.asc Description: This is a digitally signed message part.
Re: Binary naming for Django Related Packages
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-., 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 pgpPkLIxR9pNA.pgp Description: OpenPGP digital signature
Re: Binary naming for Django Related Packages
+1 On 28/11/2016 17:11, Scott Kitterman wrote: Snark on #debian-python
Re: Binary naming for Django Related Packages
[Scott Kitterman, 2016-11-28]
> I've recently done some Django related packaging for the first time and
> noticed that we have organically (as far as I can tell) grown a slightly
> different naming convention for such packages. Instead of python*-foo, we
> use
> python*-django-foo.
>
> I think this is a reasonable approach and followed it in the new packages
> I've
> recently done.
>
> I decided to check and see how common the approach is. Here's what I found
> in
> Sid:
>
> Start with django: 7
> Start w/django, not transitional: 2
> Start with django3: 0
>
> Start with python-django (excluding -doc): 136
> Start with python3-django: 84
>
> I think it would make sense to add this to the Python policy so how we're
> doing it is documented. I am attaching a proposed diff. I made it a should
> because there are two non-DPMT packages that don't follow this rule and I
> think it's late in the cycle to be adding to must policy requirements.
>
> 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
If Django packages have no use outside Django¹, they should be moved out²
of public dist-packages IMO. If they are useful, "-django" part is misleading.
[¹] dash suggest they're not in django namespace, otherwise binary
package name would be python3-django.foo
(or python3-django.ext.foo, like in flask?)
[²] 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)
--
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
[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) -- 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 Monday, November 28, 2016 05:50:24 PM Piotr Ożarowski wrote:
> [Scott Kitterman, 2016-11-28]
>
> > I've recently done some Django related packaging for the first time and
> > noticed that we have organically (as far as I can tell) grown a slightly
> > different naming convention for such packages. Instead of python*-foo, we
> > use python*-django-foo.
> >
> > I think this is a reasonable approach and followed it in the new packages
> > I've recently done.
> >
> > I decided to check and see how common the approach is. Here's what I
> > found in Sid:
> >
> > Start with django: 7
> > Start w/django, not transitional: 2
> > Start with django3: 0
> >
> > Start with python-django (excluding -doc): 136
> > Start with python3-django: 84
> >
> > I think it would make sense to add this to the Python policy so how we're
> > doing it is documented. I am attaching a proposed diff. I made it a
> > should because there are two non-DPMT packages that don't follow this
> > rule and I think it's late in the cycle to be adding to must policy
> > requirements.
> >
> > 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
>
>
> If Django packages have no use outside Django¹, they should be moved out²
> of public dist-packages IMO. If they are useful, "-django" part is
> misleading.
>
> [¹] dash suggest they're not in django namespace, otherwise binary
> package name would be python3-django.foo
> (or python3-django.ext.foo, like in flask?)
> [²] 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)
Some, but not all of them, are shipped as django_foo, so for those, I think
python*-django-foo is actually correct.
>From a django perspective, it makes a difference. As an example, django-
python-hstore (which I just packaged with python*-django-hstore binaries) is
django_hstore. When added to Django INSTALLED_APPS, it's added as
django_hstore. The django. namespace is for things shipped with Django, not
third-party packages.
Asking upstreams to rename to use django_ where they don't will complicate
things for upgrades, so I don't think that's a great idea.
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.
Thanks,
Scott K
Re: pip for stretch
On Nov 21, 2016, at 06:37 PM, Donald Stufft wrote: >As one might expect, I would prefer it if folks got 9.0.1 as quickly as >possible. In particular the feature that makes it easier for upstreams to >drop Python 2 support is one that is really only effective when people can >consider pip 9 a "minimum" version of pip to support. Getting it into the >hands of folks as quickly as possible would be a big boon to that. I'm starting to work on pip 9.0.1 but noticed two new dependencies. appdirs 1.4.0 we have, but distro 1.0.1 we don't. It doesn't look like there's an ITP for that, so I'll file that bug. Cheers, -Barry pgpHuORawNqCM.pgp Description: OpenPGP digital signature
Re: pip for stretch
On Nov 28, 2016, at 01:56 PM, Barry Warsaw wrote: >I'm starting to work on pip 9.0.1 but noticed two new dependencies. appdirs >1.4.0 we have, but distro 1.0.1 we don't. It doesn't look like there's an ITP >for that, so I'll file that bug. Okay, as soon as python-distro clears new, I'll upload pip 9.0.1. Cheers, -Barry pgpveAufZSqdG.pgp Description: OpenPGP digital signature
RFS: python-patch 1.16
Hi, I packaged python-patch as per this ITP: https://bugs.debian.org/845482, this is the repo: https://anonscm.debian.org/cgit/python-modules/packages/python-patch.git Please someone more experienced than me review it and if it's OK sponsor its upload. Please note that since the pypi tarball has no tests, whereas the github tarball has no setup, I choose the latter and added the setup.py with a git-dpm/quilt patch. I hope this is correct. Thanks, Paolo signature.asc Description: OpenPGP digital signature
RFS: python-jsonref 0.1
Hi, I packaged python-jsonref as per this ITP: https://bugs.debian.org/844986, this is the repo: https://anonscm.debian.org/cgit/python-modules/packages/python-jsonref.git Please someone more experienced than me review it and if it's OK sponsor its upload. Thanks, Paolo signature.asc Description: OpenPGP digital signature
