Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Demo not suitable for Windows, due to using uwsgi an django-dotenv #218

Open
Meteor0id opened this issue Aug 26, 2018 · 6 comments
Open

Comments

@Meteor0id
Copy link

Following the virtualenv instructions, users will hit errors.
uwsig will fail to install, since os.uname() is not available in the Windows version of Phython.
Further more the module dotenv cant be loaded (even when installing djanog-dotenv or python-dotenv)

It would probably be a good idea to allow windows users to try out Wagtail, and make sure they dont hit errors before having tried Wagtail.

@gasman
Copy link
Contributor

gasman commented Oct 27, 2018

Hi @Meteor0id - I've now updated the virtualenv installation instructions to skip installing uwsgi, as that was only really needed for Heroku deployment. Afraid I don't have a Windows setup to hand, so I can't investigate what's failing with dotenv - happy to consider any suggestions for fixing this, though.

@ChrisVanBael
Copy link

ChrisVanBael commented Jun 13, 2019

I touched upon this issue also.
Errors I had when running docker-compose run app /venv/bin/python manage.py load_initial_data:
First:

 Downloading https://files.pythonhosted.org/packages/7b/7c/c9386b82a25115cccf1903441bba3cbadcfae7b678a20167347fa8ded34c/pyasn1-0.4.5-py2.py3-none-any.whl (73kB)
ERROR: botocore 1.12.33 has requirement urllib3<1.25,>=1.20; python_version >= "3.4", but you'll have urllib3 1.25.3 which is incompatible.

Later:

Step 11/14 : RUN DATABASE_URL=postgres://none REDIS_URL=none /venv/bin/python manage.py collectstatic --noinput
 ---> Running in aab9eb68000e
/venv/lib/python3.5/site-packages/dotenv.py:56: UserWarning: Not reading .env - it doesn't exist.
  warnings.warn("Not reading {0} - it doesn't exist.".format(dotenv))
WARNING: DJANGO_SECRET_KEY not found in os.environ. Generating ephemeral SECRET_KEY.

When running docker-compose run app /venv/bin/python manage.py load_initial_data:

Starting bakerydemo_elasticsearch_1 ... done
Starting bakerydemo_redis_1         ... done
standard_init_linux.go:207: exec user process caused "no such file or directory"

Quite frustrating to not be able to see a demo of wagtail.
It would be nice to see an online demo of wagtail with the bakery data.
I can run wagtail locally by following the tutorial: http://docs.wagtail.io/en/v2.5.1/getting_started/tutorial.html
Is it possible to add the bakerydemo data to it in an easy way?

@benhadad
Copy link

benhadad commented Aug 9, 2019

I just ran into the same issue on windows. Up until the last issue with the missing directory, there were errors but the process continued.

docker-compose run app /venv/bin/python manage.py load_initial_data

I can tell part of the issue is when I look in the directory there is not "load_initial_data" file that I can see is available? Manage.py calls for a file that doesn't exist.

@spapas
Copy link

spapas commented Nov 1, 2019

It runs fine in my Windows 10 using the virtualenv method; just install the base.txt requirements.

@Amondale
Copy link
Contributor

In Windows/Docker setup, I have found that "generated" images seem to disappear between down and up cycles, and even a load_initial_data won't recreate them. Here is an example from my app logs:

[pid: 16|app: 0|req: 32/53] 172.19.0.6 () {44 vars in 888 bytes} [Sun Jun 21 14:26:47 2020] GET /media/images/bakingsoda.2e16d0ba.fill-430x254-c100_OImoI29.jpg => generated 6595 bytes in 87 msecs (HTTP/1.0 404) 5 headers in 158 bytes (1 switches on core 2)

I am assuming these files (*Olmol29.jpg, e.g.) are generated by "collect_static" in django?

Also, it is worth mentioning that I am running NGINX as a front end in my dev environment, but the above logs are coming from the upstream app docker container.

@Amondale
Copy link
Contributor

Amondale commented Jun 21, 2020

For the above issue, the workaround for me was to run:

  • docker-compose down

  • docker-compose up -d --build --force-recreate

  • docker-compose run app /venv/bin/python manage.py load_initial_data

Then the "generated" images were recreated. But I'd be curious why?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants