Closed janeeisenstein closed 3 years ago
@janeeisenstein hmmm I don't see that behavior on OSX 10.14, but I don't think that's the likely cause.
Can you try two things for me:
Try running ./manage.py migrate
before the runserver, just in case it's trying to complain about missing migrations but it's stderr is getting lost somehow.
Attach the results of pip freeze > freeze.txt
for me so I can compare versions of things.
Let me know which version of Python you're using there.
Thanks!
@frankwiles ./manage migrate
also hangs.
Here's what succeeded:
janee$ workon simpl-games-api-3.7
(simpl-games-api-3.7) softweave-2020:simpl-games-api janee$ pip install -r requirements.txt -U
(simpl-games-api-3.7) softweave-2020:simpl-games-api janee$ python --version
Python 3.7.6
(simpl-games-api-3.7) softweave-2020:simpl-games-api janee$ pip freeze > freeze.txt
I tried changing the v0.8.2 requirements to match v0.8.3 and had no problems with just django-db-geventpool==3.2.2
.
(simpl-games-api-3.7) softweave-2020:simpl-games-api janee$ pip install -r requirements.txt -U
(simpl-games-api-3.7) softweave-2020:simpl-games-api janee$ pip freeze > freeze-v0.8.2.txt
(simpl-games-api-3.7) softweave-2020:simpl-games-api janee$ ./manage.py migrate
Operations to perform:
Apply all migrations: account, admin, auth, authtoken, contenttypes, cuser, games, sessions, simpl_users, sites, socialaccount, webhook
Running migrations:
No migrations to apply.
@frankwiles These setting you added to the local settings are what's causing things to hang on my system. I'm running Postgres.app version 2.4.1 and these settings don't match my local system.
DATABASES = {
"default": {
"ENGINE": "django_db_geventpool.backends.postgresql_psycopg2",
"HOST": "db",
"USER": "postgres",
"NAME": "postgres",
"PASSWORD": "",
"PORT": 5432,
"ATOMIC_REQUESTS": False,
"CONN_MAX_AGE": 0,
"OPTIONS": {"MAX_CONNS": 50},
}
}
Commenting them out allows simpl-games-api to connect to my local Postgres server.
Changing them as follows corrects the problem -- on my system:
DATABASES = {
"default": {
"ENGINE": "django_db_geventpool.backends.postgresql_psycopg2",
"HOST": "localhost",
"USER": "janee",
"NAME": "simpl",
"PASSWORD": "",
"PORT": 5432,
"ATOMIC_REQUESTS": False,
"CONN_MAX_AGE": 0,
"OPTIONS": {"MAX_CONNS": 50},
}
}
Please correct or remove these settings.
@frankwiles The problem is also corrected if I replace your DATABASES settings with these:
DATABASES['default']['ENGINE'] = "django_db_geventpool.backends.postgresql_psycopg2"
DATABASES['default']['ATOMIC_REQUESTS'] = False
DATABASES['default']['CONN_MAX_AGE'] = 0
DATABASES['default']['OPTIONS'] = {"MAX_CONNS": 50}
It seems strange that the common settings sets:
DATABASES['default']['ATOMIC_REQUESTS'] = True
only to be followed by the local settings setting
DATABASES['default']['ATOMIC_REQUESTS'] = False
@frankwiles Many unit tests were also broken by your v0.8.3 changes.
@frankwiles These setting you added to the local settings are what's causing things to hang on my system. I'm running Postgres.app version 2.4.1 and these settings don't match my local system.
DATABASES = { "default": { "ENGINE": "django_db_geventpool.backends.postgresql_psycopg2", "HOST": "db", "USER": "postgres", "NAME": "postgres", "PASSWORD": "", "PORT": 5432, "ATOMIC_REQUESTS": False, "CONN_MAX_AGE": 0, "OPTIONS": {"MAX_CONNS": 50}, } }
Commenting them out allows simpl-games-api to connect to my local Postgres server.
Changing them as follows corrects the problem -- on my system:
DATABASES = { "default": { "ENGINE": "django_db_geventpool.backends.postgresql_psycopg2", "HOST": "localhost", "USER": "janee", "NAME": "simpl", "PASSWORD": "", "PORT": 5432, "ATOMIC_REQUESTS": False, "CONN_MAX_AGE": 0, "OPTIONS": {"MAX_CONNS": 50}, } }
Please correct or remove these settings.
@janeeisenstein you'll need to run with your own DJANGO_SETTINGS_MODULE. Setting the default local configuration to be user ejane
is ONLY going to work for you.
The default settings are the way they are so that it functions out of the box with docker.
@frankwiles This ticket is about how your settings changes cause problems running without docker.
Did you even test running your settings without docker?
@frankwiles your changes break the unit tests. This may be the right direction to be heading, but broken unit tests are unacceptable.
yes I ran them in a plain old 3.7 venv with only PG in docker listening on localhost:5432, I just didn't use config.settings.local
as that wouldn't work. Perhaps we should rename that to be config-settings.compose
or something.
I just pushed up a fix for the one unit test that was broken related to making it easier to use this outside docker. If you're seeing lots of failed tests it's because it can't connect to the DB.
Just ran through it all again from scratch and it's fine for me. Logs and screenshot included.
simpl-pytest-run.txt
@frankwiles moving docker-compose specific settings to a new file sounds good to me. In the meantime Travis doesn't approve of your latest changes: https://travis-ci.com/github/simplworld/simpl-games-api/builds/216257067
The default settings are the way they are so that it functions out of the box with docker.
@frankwiles we need a local settings that doesn't presuppose/require running PostgreSql in docker.
@frankwiles With your fix to the test settings, replacing your docker specific DATABASES local settings with these agnostic settings:
DATABASES['default']['ENGINE'] = "django_db_geventpool.backends.postgresql_psycopg2"
DATABASES['default']['ATOMIC_REQUESTS'] = False
DATABASES['default']['CONN_MAX_AGE'] = 0
DATABASES['default']['OPTIONS'] = {"MAX_CONNS": 50}
allows the unit tests to successfully run as well as ./manage.py runserver 0.0.0.0:8100
in my local development environment.
However, these settings prevent running with docker-compose.
Corrected docker.compose.yml and completed fix for problems in v0.8.3 in this pull request https://github.com/simplworld/simpl-games-api/pull/40
Merged #40 and tagged as v0.8.4.
Under Mac OS 10.15.7, v0.8.3 fails to come up.
With v0.8.3 installed, running:
resulted in this console output:
With v0.8.2 installed, running the same commands resulted in this console output: