Cookiecutter-django: docker-compose -f local.yml up fails on windows

Created on 20 May 2019 · 16Comments · Source: pydanny/cookiecutter-django

What happened?

I am trying to start a new project on windows using docker. Here are my settings

cookiecutter https://github.com/pydanny/cookiecutter-django
You've downloaded C:\Users\srao.cookiecutters\cookiecutter-django before. Is it okay to delete and re-download it? [yes]: yes
project_name [My Awesome Project]:
project_slug [my_awesome_project]:
description [Behold My Awesome Project!]:
author_name [Daniel Roy Greenfeld]:
domain_name [example.com]:
email [[email protected]]:
version [0.1.0]:
Select open_source_license:
1 - MIT
2 - BSD
3 - GPLv3
4 - Apache Software License 2.0
5 - Not open source
Choose from 1, 2, 3, 4, 5 (1, 2, 3, 4, 5) [1]:
timezone [UTC]:
windows [n]: y
use_pycharm [n]:
use_docker [n]: y
Select postgresql_version:
1 - 10.5
2 - 10.4
3 - 10.3
4 - 10.2
5 - 10.1
6 - 9.6
7 - 9.5
8 - 9.4
Choose from 1, 2, 3, 4, 5, 6, 7, 8 (1, 2, 3, 4, 5, 6, 7, 8) [1]:
Select js_task_runner:
1 - None
2 - Gulp
Choose from 1, 2 (1, 2) [1]:
Select cloud_provider:
1 - AWS
2 - GCE
Choose from 1, 2 (1, 2) [1]:
custom_bootstrap_compilation [n]:
use_compressor [n]:
use_celery [n]:
use_mailhog [n]: y
use_sentry [n]:
use_whitenoise [n]:
use_heroku [n]:
use_travisci [n]:
keep_local_envs_in_vcs [y]:
debug [n]:
[SUCCESS]: Project initialized, keep up the good work!

The build succeeds with docker-compose -f local.yml build and the django_1 container fails after I execute docker-compose -f local.yml up
The error is

django_1 | Running on http://0.0.0.0:8000/ (Press CTRL+C to quit)
django_1 | Restarting with stat
': No such file or directorycute 'python
my_awesome_project_django_1 exited with code 127

I am on Docker version 18.09.2, build 6247962 and docker-compose version 1.23.2, build 1110ad01
Any ideas on what I am doing wrong?

What should've happened instead?

Steps to reproduce

bug docker windows

Source

shireenrao

Most helpful comment

I think this maybe is related to werkzeug. Check this discussion https://github.com/pallets/werkzeug/issues/1482 . And a possible (?) fix https://github.com/pallets/werkzeug/issues/1482#issuecomment-477437009

demestav on 21 May 2019

👍2

All 16 comments

Thanks for the report. Unfortunately, I don't own a Windows machine... If you use Docker, the differences should be minimal I think.

Can you try to do the same but answering n to the Windows question?

browniebroke on 21 May 2019

I just tried it with answering n for the windows question.. unfortunately and am seeing the same error. I can help in investigating the issue, but need some help with debugging the docker setup.

shireenrao on 21 May 2019

demestav on 21 May 2019

👍2

Good find! It looks like reverting to Werkzeug 0.14 would be a quick way to confirm whether this is the problem... If someone with access to a Windows machine could try this out and report back that would be great.

I'm not yet clear what the proper fix is, pull requests welcome.

browniebroke on 21 May 2019

I submitted a pull request to revert the local requirements back to Werkzeug 0.14. As this is limited to just the local settings I think this is safe to do. Let me know if this is ok.

shireenrao on 22 May 2019

Commented on the pull request. This is only a workaround though.

I suppose you don't have this problem when running tests, do you?

docker-compose -f local.yml run django pytest

browniebroke on 22 May 2019

I ran the tests with both Werkzeug 0.14.1 and 0.15. They all succeeded. I have also updated my pull request to 0.14.1 and added the pyup filter.

shireenrao on 22 May 2019

Ok thanks. PR merged.

browniebroke on 22 May 2019

Will close this issue and open another one to upgrade Werkzeug with a caveat for testing on Windows

browniebroke on 22 May 2019

@shireenrao if you have a minute, could you please try out the upgrade/werkzeug-0.15 branch where I've attempted a fix:

cookiecutter https://github.com/pydanny/cookiecutter-django --checkout upgrade/werkzeug-0.15

browniebroke on 28 May 2019

@browniebroke I am now seeing the following error

Creating network "saturn_default" with the default driver
Creating volume "saturn_local_postgres_data" with default driver
Creating volume "saturn_local_postgres_data_backups" with default driver
Pulling mailhog (mailhog/mailhog:v1.0.0)...
v1.0.0: Pulling from mailhog/mailhog
709515475419: Pull complete
77149838f736: Pull complete
2f54c530afe7: Pull complete
ba455da900f1: Pull complete
Creating saturn_postgres_1 ... done
Creating saturn_mailhog_1  ... done
Creating saturn_django_1   ... done
Attaching to saturn_postgres_1, saturn_mailhog_1, saturn_django_1
postgres_1  | The files belonging to this database system will be owned by user "postgres".
postgres_1  | This user must also own the server process.
postgres_1  |
postgres_1  | The database cluster will be initialized with locale "en_US.utf8".
postgres_1  | The default database encoding has accordingly been set to "UTF8".
postgres_1  | The default text search configuration will be set to "english".
postgres_1  |
postgres_1  | Data page checksums are disabled.
postgres_1  |
postgres_1  | fixing permissions on existing directory /var/lib/postgresql/data ... ok
postgres_1  | creating subdirectories ... ok
postgres_1  | selecting default max_connections ... 100
postgres_1  | selecting default shared_buffers ... 128MB
postgres_1  | selecting dynamic shared memory implementation ... posix
postgres_1  | creating configuration files ... ok
mailhog_1   | 2019/05/28 17:22:45 Using in-memory storage
mailhog_1   | 2019/05/28 17:22:45 [SMTP] Binding to address: 0.0.0.0:1025
mailhog_1   | [HTTP] Binding to address: 0.0.0.0:8025
mailhog_1   | 2019/05/28 17:22:45 Serving under http://0.0.0.0:8025/
mailhog_1   | Creating API v1 with WebPath:
mailhog_1   | Creating API v2 with WebPath:
django_1    | Waiting for PostgreSQL to become available...
postgres_1  | running bootstrap script ... ok
postgres_1  | performing post-bootstrap initialization ... ok
postgres_1  | syncing data to disk ... ok
postgres_1  |
postgres_1  | Success. You can now start the database server using:
postgres_1  |
postgres_1  |     pg_ctl -D /var/lib/postgresql/data -l logfile start
postgres_1  |
postgres_1  |
postgres_1  | WARNING: enabling "trust" authentication for local connections
postgres_1  | You can change this by editing pg_hba.conf or using the option -A, or
postgres_1  | --auth-local and --auth-host, the next time you run initdb.
postgres_1  | waiting for server to start....2019-05-28 17:22:46.981 UTC [41] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1  | 2019-05-28 17:22:47.001 UTC [42] LOG:  database system was shut down at 2019-05-28 17:22:46 UTC
postgres_1  | 2019-05-28 17:22:47.006 UTC [41] LOG:  database system is ready to accept connections
postgres_1  |  done
postgres_1  | server started
django_1    | Waiting for PostgreSQL to become available...
postgres_1  | CREATE DATABASE
postgres_1  |
postgres_1  |
postgres_1  | /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
postgres_1  |
postgres_1  | waiting for server to shut down....2019-05-28 17:22:47.439 UTC [41] LOG:  received fast shutdown request
postgres_1  | 2019-05-28 17:22:47.443 UTC [41] LOG:  aborting any active transactions
postgres_1  | 2019-05-28 17:22:47.446 UTC [41] LOG:  background worker "logical replication launcher" (PID 48) exited with exit code 1
postgres_1  | 2019-05-28 17:22:47.446 UTC [43] LOG:  shutting down
postgres_1  | 2019-05-28 17:22:47.465 UTC [41] LOG:  database system is shut down
postgres_1  |  done
postgres_1  | server stopped
postgres_1  |
postgres_1  | PostgreSQL init process complete; ready for start up.
postgres_1  |
postgres_1  | 2019-05-28 17:22:47.553 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
postgres_1  | 2019-05-28 17:22:47.554 UTC [1] LOG:  listening on IPv6 address "::", port 5432
postgres_1  | 2019-05-28 17:22:47.559 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1  | 2019-05-28 17:22:47.573 UTC [59] LOG:  database system was shut down at 2019-05-28 17:22:47 UTC
postgres_1  | 2019-05-28 17:22:47.578 UTC [1] LOG:  database system is ready to accept connections
django_1    | PostgreSQL is available
django_1    | Operations to perform:
django_1    |   Apply all migrations: account, admin, auth, contenttypes, sessions, sites, socialaccount, users
django_1    | Running migrations:
django_1    |   Applying contenttypes.0001_initial... OK
django_1    |   Applying contenttypes.0002_remove_content_type_name... OK
django_1    |   Applying auth.0001_initial... OK
django_1    |   Applying auth.0002_alter_permission_name_max_length... OK
django_1    |   Applying auth.0003_alter_user_email_max_length... OK
django_1    |   Applying auth.0004_alter_user_username_opts... OK
django_1    |   Applying auth.0005_alter_user_last_login_null... OK
django_1    |   Applying auth.0006_require_contenttypes_0002... OK
django_1    |   Applying auth.0007_alter_validators_add_error_messages... OK
django_1    |   Applying auth.0008_alter_user_username_max_length... OK
django_1    |   Applying users.0001_initial... OK
django_1    |   Applying account.0001_initial... OK
django_1    |   Applying account.0002_email_max_length... OK
django_1    |   Applying admin.0001_initial... OK
django_1    |   Applying admin.0002_logentry_remove_auto_add... OK
django_1    |   Applying admin.0003_logentry_add_action_flag_choices... OK
django_1    |   Applying auth.0009_alter_user_last_name_max_length... OK
django_1    |   Applying auth.0010_alter_group_name_max_length... OK
django_1    |   Applying auth.0011_update_proxy_permissions... OK
django_1    |   Applying sessions.0001_initial... OK
django_1    |   Applying sites.0001_initial... OK
django_1    |   Applying sites.0002_alter_domain_unique... OK
django_1    |   Applying sites.0003_set_site_domain_and_name... OK
django_1    |   Applying socialaccount.0001_initial... OK
django_1    |   Applying socialaccount.0002_token_max_lengths... OK
django_1    |   Applying socialaccount.0003_extra_data_default_dict... OK
django_1    |  * Running on http://0.0.0.0:8000/ (Press CTRL+C to quit)
django_1    |  * Restarting with stat
django_1    | Traceback (most recent call last):
django_1    |   File "manage.py", line 30, in <module>
django_1    |     execute_from_command_line(sys.argv)
django_1    |   File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
django_1    |     utility.execute()
django_1    |   File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 375, in execute
django_1    |     self.fetch_command(subcommand).run_from_argv(self.argv)
django_1    |   File "/usr/local/lib/python3.6/site-packages/django/core/management/base.py", line 323, in run_from_argv
django_1    |     self.execute(*args, **cmd_options)
django_1    |   File "/usr/local/lib/python3.6/site-packages/django/core/management/base.py", line 364, in execute
django_1    |     output = self.handle(*args, **options)
django_1    |   File "/usr/local/lib/python3.6/site-packages/django_extensions/management/utils.py", line 62, in inner
django_1    |     ret = func(self, *args, **kwargs)
django_1    |   File "/usr/local/lib/python3.6/site-packages/django_extensions/management/commands/runserver_plus.py", line 262, in handle
django_1    |     self.inner_run(options)
django_1    |   File "/usr/local/lib/python3.6/site-packages/django_extensions/management/commands/runserver_plus.py", line 388, in inner_run
django_1    |     ssl_context=ssl_context,
django_1    |   File "/usr/local/lib/python3.6/site-packages/werkzeug/serving.py", line 1007, in run_simple
django_1    |     run_with_reloader(inner, extra_files, reloader_interval, reloader_type)
django_1    |   File "/usr/local/lib/python3.6/site-packages/werkzeug/_reloader.py", line 332, in run_with_reloader
django_1    |     sys.exit(reloader.restart_with_reloader())
django_1    |   File "/usr/local/lib/python3.6/site-packages/werkzeug/_reloader.py", line 176, in restart_with_reloader
django_1    |     exit_code = subprocess.call(args, env=new_environ, close_fds=False)
django_1    |   File "/usr/local/lib/python3.6/subprocess.py", line 287, in call
django_1    |     with Popen(*popenargs, **kwargs) as p:
django_1    |   File "/usr/local/lib/python3.6/subprocess.py", line 729, in __init__
django_1    |     restore_signals, start_new_session)
django_1    |   File "/usr/local/lib/python3.6/subprocess.py", line 1364, in _execute_child
django_1    |     raise child_exception_type(errno_num, err_msg, err_filename)
django_1    | FileNotFoundError: [Errno 2] No such file or directory: '/app/manage.py': '/app/manage.py'
saturn_django_1 exited with code 1

shireenrao on 28 May 2019

Thanks for testing quickly! Just added one more thing, which might fix the above error.

browniebroke on 28 May 2019

Did you already commit your change? I just tried it again and am seeing the same error.

shireenrao on 28 May 2019

Yea. The fix doesn't work then 😞

browniebroke on 28 May 2019

I am wondering where the /app/manage.py in the error comes from.

demestav on 28 May 2019

I think It is coming from the django docker image.

shireenrao on 28 May 2019

Was this page helpful?