Hello Raphael,
> On 7 Dec 2016, at 11:39, Raphael Hertzog <[email protected]> wrote:
>
> Would you agree to add this recommendation somewhere in the official
> Django doc?
In my experience:
- many Django-related packages use a django- prefix in the name of the package
on PyPI
- very few use a django_ prefix in the name of the Python module, because this
module can only be used in the context of Django and the longer name makes
imports less readable
For example here’s a typical INSTALLED_APPS settings:
INSTALLED_APPS = [
# redacted project-specific apps…
'allauth', # provides templates and translations
'allauth.account', # provides email-related models
'allauth.socialaccount', # provides social-related models
'allauth.socialaccount.providers.facebook',
'allauth.socialaccount.providers.google',
'allauth.socialaccount.providers.linkedin_oauth2',
'allauth.socialaccount.providers.twitter',
'django_rq',
'django_s3_storage',
'impersonate',
'localflavor',
'modelcluster', # required by wagtail
'overextends', # to customize wagtail
'phonenumber_field',
'raven.contrib.django.raven_compat',
'rest_framework',
'sequences.apps.SequencesConfig',
'taggit', # required by wagtail
'waffle',
# Work around https://github.com/torchbox/wagtail/issues/1824
'wagtail.contrib.wagtailsearchpromotions',
'wagtail.contrib.wagtailstyleguide',
'wagtail.wagtailadmin',
'wagtail.wagtailcore',
'wagtail.wagtaildocs',
'wagtail.wagtailembeds',
'wagtail.wagtailforms',
'wagtail.wagtailimages',
'wagtail.wagtailredirects',
'wagtail.wagtailsearch',
'wagtail.wagtailsites',
'wagtail.wagtailsnippets',
'wagtail.wagtailusers',
'webpack_loader',
'whitenoise.runserver_nostatic', # before django.contrib.staticfiles
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.messages',
'django.contrib.postgres',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.staticfiles',
]
Two packages follow your idea: django_rq and django_s3_storage.
django_rq is called like that because rq exists independently of Django and
django_rq is a separate project.
django_s3_storage could be called s3_storage. This may be an oversight or a
choice of the maintainer. It's an isolated case though.
Considering the backwards-compatibility issues — if you change a package name
all imports needs updating — I don’t think it’s realistic to go against the
established practice of the ecosystem at this point, and for this reason I'm
not in favor of making that recommandation.
Since changes I made in 1.7, the documentation recommends to use the
"<app_label>.apps.<AppName>Config" convention in INSTALLED_APPS. We're at
1.10, and as you can see in the example above, this isn't a resounding
success... The only app using that convention in the list is one I wrote.
I believe recommending a django_ prefix would be even less successful.
To sum up, I’m afraid that your suggestion priorizes the needs of packagers
over those of developers and, unfortunately for you, developers are the
heavier users there.
Best regards,
--
Aymeric.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/19E4A2A8-E152-446B-9938-007CF317033B%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
