How to change the name of a Django app?

I have changed the name of an app in Django by renaming its folder, imports and all its references (templates/indexes). But now I get this error when I try to run python manage.py runserver

Error: Could not import settings 'nameofmynewapp.settings' (Is it on sys.path?): No module named settings

How can I debug and solve this error? Any clues?

Solution 1:

Follow these steps to change an app's name in Django:

Rename the folder which is in your project root
Change any references to your app in their dependencies, i.e. the app's views.py, urls.py , manage.py , and settings.py files.
Edit the database table django_content_type with the following command: UPDATE django_content_type SET app_label='<NewAppName>' WHERE app_label='<OldAppName>'
Also, if you have models, you will have to rename the model tables. For postgres, use ALTER TABLE <oldAppName>_modelName RENAME TO <newAppName>_modelName. For mysql too, I think it is the same (as mentioned by @null_radix).
(For Django >= 1.7) Update the django_migrations table to avoid having your previous migrations re-run: UPDATE django_migrations SET app='<NewAppName>' WHERE app='<OldAppName>'. Note: there is some debate (in comments) if this step is required for Django 1.8+; If someone knows for sure please update here.
If your models.py 's Meta Class has app_name listed, make sure to rename that too (mentioned by @will).
If you've namespaced your static or templates folders inside your app, you'll also need to rename those. For example, rename old_app/static/old_app to new_app/static/new_app.
For renaming django models, you'll need to change django_content_type.name entry in DB. For postgreSQL, use UPDATE django_content_type SET name='<newModelName>' where name='<oldModelName>' AND app_label='<OldAppName>'
Update 16Jul2021: Also, the __pycache__/ folder inside the app must be removed, otherwise you get EOFError: marshal data too short when trying to run the server. Mentioned by @Serhii Kushchenko

Meta point (If using virtualenv): Worth noting, if you are renaming the directory that contains your virtualenv, there will likely be several files in your env that contain an absolute path and will also need to be updated. If you are getting errors such as ImportError: No module named ... this might be the culprit. (thanks to @danyamachine for providing this).

Other references: you might also want to refer to the below links for a more complete picture:

Renaming an app with Django and South
How do I migrate a model out of one django app and into a new one?
How to change the name of a Django app?
Backwards migration with Django South
Easiest way to rename a model using Django/South?
Python code (thanks to A.Raouf) to automate the above steps (Untested code. You have been warned!)
Python code (thanks to rafaponieman) to automate the above steps (Untested code. You have been warned!)

Solution 2:

New in Django 1.7 is a app registry that stores configuration and provides introspection. This machinery let's you change several app attributes.

The main point I want to make is that renaming an app isn't always necessary: With app configuration it is possible to resolve conflicting apps. But also the way to go if your app needs friendly naming.

As an example I want to name my polls app 'Feedback from users'. It goes like this:

Create a apps.py file in the polls directory:

from django.apps import AppConfig

class PollsConfig(AppConfig):
    name = 'polls'
    verbose_name = "Feedback from users"

Add the default app config to your polls/__init__.py:

default_app_config = 'polls.apps.PollsConfig'

For more app configuration: https://docs.djangoproject.com/en/1.7/ref/applications/

Solution 3:

Fun problem! I'm going to have to rename a lot of apps soon, so I did a dry run.

This method allows progress to be made in atomic steps, to minimise disruption for other developers working on the app you're renaming.

See the link at the bottom of this answer for working example code.

Prepare existing code for the move:
- Create an app config (set name and label to defaults).
- Add the app config to INSTALLED_APPS.
- On all models, explicitly set db_table to the current value.
- Doctor migrations so that db_table was "always" explicitly defined.
- Ensure no migrations are required (checks previous step).
Change the app label:
- Set label in app config to new app name.
- Update migrations and foreign keys to reference new app label.
- Update templates for generic class-based views (the default path is <app_label>/<model_name>_<suffix>.html)
- Run raw SQL to fix migrations and content_types app (unfortunately, some raw SQL is unavoidable). You can not run this in a migration.
```
UPDATE django_migrations
   SET app = 'catalogue'
 WHERE app = 'shop';

UPDATE django_content_type
   SET app_label = 'catalogue'
 WHERE app_label = 'shop';
```
- Ensure no migrations are required (checks previous step).
Rename the tables:
- Remove "custom" db_table.
- Run makemigrations so django can rename the table "to the default".
Move the files:
- Rename module directory.
- Fix imports.
- Update app config's name.
- Update where INSTALLED_APPS references the app config.
Tidy up:
- Remove custom app config if it's no longer required.
- If app config gone, don't forget to also remove it from INSTALLED_APPS.

Example solution: I've created app-rename-example, an example project where you can see how I renamed an app, one commit at a time.

The example uses Python 2.7 and Django 1.8, but I'm confident the same process will work on at least Python 3.6 and Django 2.1.

Solution 4:

In case you are using PyCharm and project stops working after rename:

Edit Run/Debug configuration and change environment variable DJANGO_SETTINGS_MODULE, since it includes your project name.
Go to Settings / Languages & Frameworks / Django and update the settings file location.

Solution 5:

In many cases, I believe @allcaps's answer works well.

However, sometimes it is necessary to actually rename an app, e.g. to improve code readability or prevent confusion.

Most of the other answers involve either manual database manipulation or tinkering with existing migrations, which I do not like very much.

As an alternative, I like to create a new app with the desired name, copy everything over, make sure it works, then remove the original app:

Start a new app with the desired name, and copy all code from the original app into that. Make sure you fix the namespaced stuff, in the newly copied code, to match the new app name.
makemigrations and migrate. Note: if the app has a lot of foreign keys, there will likely be issues with clashing reverse accessors when trying to run the initial migration for the copied app. You have to rename the related_name accessor (or add new ones) on the old app to resolve the clashes.
Create a data migration that copies the relevant data from the original app's tables into the new app's tables, and migrate again.

At this point, everything still works, because the original app and its data are still in place.

Now you can refactor all the dependent code, so it only makes use of the new app. See other answers for examples of what to look out for.
Once you are certain that everything works, you can remove the original app. This involves another (schema) migration.

This has the advantage that every step uses the normal Django migration mechanism, without manual database manipulation, and we can track everything in source control. In addition, we keep the original app and its data in place until we are sure everything works.