Django ftyctl launch makemigrations: exit status 1

launching a new Django app and getting hit with:

Error failed running /usr/bin/python makemigrations: exit status 1

I just ran a Django app yesterday and didn’t run into any issues. Could this be a docker issue? This error is triggering after the first few steps of ‘flyctl launch’, right after it says Setting SECRETS.

I’m having the same issue with docker and django, too. It’s strange that fly launch would run makemigrations on my local machine, though I don’t understand how fly launch works — perhaps it’s building the app locally and then launching it? In which case, shouldn’t it be running that within the docker container?

Before this issue, I kept getting Error python not found in $PATH - make sure app dependencies are installed and try again, then I realized that it was trying to use the python $PATH for my local machine, which I wasn’t expecting since the app is docker-ized.

Hi guys - did anyone find a solution to this? I am using Docker locally for development without venv and I just can’t get past the Error failed running python3 makemigrations: exit status 1 error message.

I don’t want to makemigrations, I already have them in my app - all I want to do is deploy Django so I can then import my own postgres database, and without using venv locally.

Thanks in advance.

1 Like

I’m having the same issue as @hamishau — really odd that it’s running migrations locally!

@hamishau I think I figured it out — this is really weird as I deployed another project a couple of days ago and I didn’t run into this issue.

Here’s what my DATABASES configuration looks like:

DATABASES = {'default': dj_database_url.config(conn_max_age=600)}
    "ENGINE": "django.db.backends.postgresql_psycopg2",
    "OPTIONS": {"connect_timeout": 5}

Step 1: Add a 'NAME to the DATABASES[‘default’] dict:

DATABASES = {'default': dj_database_url.config(conn_max_age=600)}
    "ENGINE": "django.db.backends.postgresql_psycopg2",
    "OPTIONS": {"connect_timeout": 5},
    "NAME": "test"

With this, the fly launch command should work.

If you want to then do fly deploy:

2a) Make sure you update the Dockerfile CMD line to have your project name
2b) Go ahead and REMOVE the NAME line from your DATABASES configuration

I have no idea why this worked.

The solution is to add a name to databases config whilst using dj-database-url? Hard to see how that would make a difference, but in saying that we don’t have anything meaningful in the way of Django documentation.

Please note I wasn’t deploying with dj-database-url in my requirements or imported into my settings, so maybe the deployment process detects this. Give me a day or so to see if I can get the same result.

No matter what I try, always attempts to makemigrations, I can’t get the behaviour to change just by tweaking the DATABASE setting. However, my issue is not necessarily that this happens, it is more to do with me not using venv locally so the requirements are missing to complete this process. I get this is an edge case, and not representative of the majority - it was easy enough to briefly use venv or vagrant or whatever to install requirements and move forward.

My issue is that makemigrations should be a flag or option during launch, so new Django sites it would be fine to run, but those of us with existing sites should be able to use a flag like fly launch --disable-makemigrations or similar. This may well exist but I can’t find it anywhere in the documentation.

I did see this on the timeline so maybe things like improve soon with Django deployment:

@hamishau Without a lot of context about your app, I’d first suggest you check the CSRF_TRUSTED_ORIGINS:

CSRF_TRUSTED_ORIGINS = [“https://*”]

It should start with a schema (http:// or https://).

I reproduced the problem locally on fly launch and missing schema. I got this error when trying to run makemigrations manually:

❯ python3 makemigrations
SystemCheckError: System check identified some issues:

?: (4_0.E001) As of Django 4.0, the values in the CSRF_TRUSTED_ORIGINS setting must start with a scheme (usually http:// or https://) but found * See the release notes for details.

Hi @katia I think there might be some confusion - my app works fine, I’m not having issues with makemigrations. My issue is the fly launch process runs makemigrations locally which just won’t work with my setup - hence getting the exit status 1 error.

All I am asking for is some sort of flag so I can stop fly launch from making migrations, I don’t believe it should be a part of the app deployment process, or at the least it should be an option.

I can get around this by creating a venv/vagrant box to install dependencies and get past the fly launch process, it’s just painful to do this every time although I understand I am in the minority.

@hamishau yes, I agree and already discussed some changes for Django fly launch. makemigrations command should be optional (having the possibility to check and run the makemigrations at this point, warning us in case there are any migrations missing but not blocking the launch process) and we should assume the migrations are ready for deployment at this point. :slight_smile: