Closed defbyte closed 8 years ago
Locally tests pass @sshami
I will destroy my VM and recreate
Issue emanating from django-jinja
:
=> default: File "/home/vagrant/.pyenv/versions/peacecorps/lib/python3.4/site-packages/django_jinja/base.py", line 14, in <module>
==> default: from django.utils.importlib import import_module
Problem solved @sshami:
django-debug-toolbar
requires the latest and greatest version of Django. Our requirements specify a range for Django. And for some reason, Pip was thoroughly confused and this was happening:
Downloading/unpacking Django>=1.8 (from django-debug-toolbar->-r requirements-dev.txt (line 3))
Downloading Django-1.10-py2.py3-none-any.whl (6.8MB): 6.8MB downloaded
I have no idea why, after discovering that Django 1.8
was't available, that it began downloading Django 1.10
@defbyte Thanks for getting this solved! I guess from now on, pinning versions is the way to go to avoid these unexpected dependency errors.
Definitely @sshami here are some resources and discussions about dependency management:
Pin Your Packages (the author then pitches some tools he built pip-tools
):
http://nvie.com/posts/pin-your-packages/
Another look at pinning requirements, using what we already know, without another tool: http://www.kennethreitz.org/essays/a-better-pip-workflow
@defbyte Great resources, thanks! p.s. - didn't know you could use emojis on Github commit messages - now I'm gonna abuse them :wink:
Pin requirements to match production, so that fresh provisioning doesn't install a version of a requirement that's versioned beyond what the application is expecting.