Checklist:
related: https://github.com/pydanny/cookiecutter-django/pull/702
Generated layout works on Docker other than #704 opened 18 hours ago by ssteinerx
Pycharm container also crashes immediately with no output other than exited with code 0.
Verified that the tests pass on 1.10
Dependencies that are Django version-dependent:
Check off each of the above when it officially works on 1.10.
django-model-utils is not ready, see the latest change log in #709
django-extensions is not ready, see https://github.com/django-extensions/django-extensions/pull/934
django-test-plus is not ready, see https://github.com/revsys/django-test-plus/pull/45
django-debug-toolbar is not ready, see https://github.com/jazzband/django-debug-toolbar/pull/864
@jayfk, the following libraries are now ready and marked as such in the checklist:
馃憤
django-braces test suite passes on Django 1.10
https://github.com/brack3t/django-braces/pull/212
django-floppyforms still require a lot of work to run with Django 1.10
See travis-ci tests of this pull-request https://github.com/gregmuellegger/django-floppyforms/pull/178
@luzfcb Cookiecutter Django doesn't actually use django-floppyforms. We use it, sometimes. Perhaps it behooves us to remove it as a dependency?
The following work with 1.10 and are marked as such on the checklist
Removed django-floppyforms in 28542a91a4a5f8f3ed121182c88269da19770e02
@audreyr Django extensions was updated 5 days ago and now says: Django Extensions requires Django 1.8 or later and one of the recent commits says "Add Django 1.10 trove classifier" so I think that can be checked off.
Django-redis is also passing this on all supported versions of Python:
```... env variables from .travis.yml $ export DJANGO="Django>=1.10,<1.11"
IOW, cookiecutter-django for Django 1.10 is ready to rock vis-脿-vis the dependency list!
IOW, cookiecutter-django for Django 1.10 is ready to rock vis-脿-vis the dependency list!
Apparently, django-coverage-plugin is not ready: https://github.com/nedbat/django_coverage_plugin/issues/28
@jayfk I actually spent a couple of hours today trying to figure out how to resolve
https://github.com/nedbat/django_coverage_plugin/issues/28.
It's a very deep issue with the new template handlers and I've been away from Django long enough (last seriously involved circa 1.5ish) that while I understand the issue, I am completely unfamiliar with the changes that went in in 1.8 that completely break .django_coverage_plugin.
The long IRC discussion was interesting, enlightening in some ways, and left me completely clueless as to how to resolve the issue.
That it's been unresolved this long makes me think we should consider dropping the dependency and moving on. It's a "nice to have" but not the end of the world if it's not there and I, for one, am not willing to hang back a version indefinitely for this one thing, especially with Channels coming in soon...
Good call. If this is a deeper issue, I'm in favor of dropping it for now (and watch it closely thereafter) to get 1.10 out of the door.
This is the killer issue: https://github.com/nedbat/django_coverage_plugin/issues/26
Read the IRC chat, this is going to be a bear to untangle if it even ever gets done.
Is there a way to fake pyup-bot out into notifying us of a change on something we're not really depending on (so we don't have to remember to check, and will be notified as soon as django_coverage_plugin has a new release?)
If so, that makes it even easier to ditch it until it's resolved as we'll have a machine watching for changes and, if they never come, it'll consume zero human-cycles.
We could pull it out of the main requirement files (so that it won't be installed) and place it in a separate file like requirements_to_watch.txt or something.
@jayfk -- you have no idea how bad I just wanted to say "Make it So", tug on my shirt, and head back to my "Ready Room" to order some Tea, Earl Grey, hot ;-).
We could pull it out of the main requirement files (so that it won't be installed) and place it in a separate file like requirements_to_watch.txt or something.
good, simple and will work.
@luzfcb What is pyup-bot's rule? If it begins with 'requirements`, its contents are added to the list of things to watch? If so, this'd be perfect!
If it begins with 'requirements`, its contents are added to the list of things to watch? If so, this'd be perfect!
Exactly, done in https://github.com/pydanny/cookiecutter-django/pull/783.
Looks like we're ready, right?
Is the removal of React/WebPack merged into master yet? I thought I saw @pydanny do that the other day, but I wasn't paying attention to where it got merged _to_.
I think he merged master to the remove-react-for-now branch, but I don't think it was merged back the other way.
@ssteinerx
@luzfcb What is pyup-bot's rule? If it begins with 'requirements`, its contents are added to the list of things to watch? If so, this'd be perfect!
the rules are documented in: https://pyup.io/docs/configuration/#requirement-file-search
@luzfcb Cool. Wasn't being lazy, would have looked it up if necessary, just knew someone here would know to make sure we let the machines do the work.
@luzfcb I should hire you :)
I can help with this: Check PyCharm 2016.2 compatibility, with and widout docker if we've got a release candidate branch going...
maybe we should continue the discussion on gitter as it gets pretty noisy for everyone not involved in the release process if we continue with this passion.
@jayfk agreed, I'll find the link and head there now.
I don't think raven (Sentry) is ready for 1.10 just yet.
https://github.com/getsentry/raven-python/issues/858 and https://github.com/getsentry/raven-python/pull/860
I may be missing something, but it looks like django-storages-redux is "now released on PyPI as django-storages" as of 2-7-2016 (see https://github.com/jschneier/django-storages/blob/master/CHANGELOG.rst). So our requirements/production for this should now list django-storages==1.5.1
@jhancia thank you, I really had not seen it.
Closing as resolved