I'm trying to launch a web2py app I made using pythonanywhere. I packaged the app and then uploaded it using the admin site, but now when I go to the page it's supposed to be on I get the error "requires web2py 2.15.5 or newer"
What does this mean? And is there a way I can go about solving this without needing to rewrite my webapp?
Thanks!
The error message is coming from these lines in the db.py model file of the scaffolding application:
if request.global_settings.web2py_version < "2.15.5":
raise HTTP(500, "Requires web2py 2.15.5 or newer")
Presumably you are somehow using the scaffolding application from web2py 2.15.5+ with an earlier version of web2py. You can try removing those lines, and everything may work, but there may be some code in the scaffolding app that relies on features available only in version 2.15.5 or later.
Alternatively, use the scaffolding app that comes with you installed version of web2py, or upgrade web2py to the latest version.
Related
I have a problem with developing a Django website. I started out with using CDN Boostrap and JS as recommended in Boostrap 5 docs but then I wanted to customize the CSS, so I changed the setup to compile Bootstrap's source scss files with django-libsass. I followed the installation guides for django-libsass and django-compressor.
What I discovered is that while everything works, it works very slow on my local machine (5-6s per opening a new page). I'm not very experienced in web development so I'm not sure what could be causing this.
If it's relevant, I don't use a frontend yet and I'm sticking to Django's templates.
I tried to download a sample django libsass project and put bootstrap there and the outcome was the same.
I expected the time for loading the pages to increase slightly due to the fact that now it has to compile scss files but not so much.
Googling turned up no results:(
Is this an expected behavior when debugging from a local machine or am I missing something? Huge thanks!
The django version is 1.9.2.
I have my website on two different servers ( the same website) the problem is that the Django admin interface on the first server is different from that on the second here are some screenshots of the two copies of the admin website
Before upgrading to a new Django version it is smart to read the release notes. Not only the release notes of the target but all versions in between. That way you know what you are going for.
1.9 introduces new styling see: https://docs.djangoproject.com/en/1.10/releases/1.9/#new-styling-for-contrib-admin
New styling for contrib.admin
The admin sports a modern, flat design with new SVG icons which look perfect on HiDPI screens. It still provides a fully-functional experience to YUI’s A-grade browsers. Older browser may experience varying levels of graceful degradation.
You run your website on two different machines each with another Django versions installed. By deploying to a new server with newer Django you 'unknowingly upgraded'. Inspect the version you are using with:
$ python manage.py version
Downgrade Django to get your old admin style back.
The design of the Django admin has changed in the 1.9 release. If you think you have upgraded both projects to Django >= 1.9, you must check your requirements, since the first one clearly still runs with Django 1.8 or less.
I am attempting to follow Tutorial: Adding Facebook/Twitter/Google Authentication to a Django Application. The only thing I am doing differently is that I am running DjangoAppEngine on the Google App Engine development server, otherwise everything is exactly as per the tutorial.
When I get to Step 4 and actually try to authenticate with Facebook, I am getting a runtime error:
error('illegal IP address string passed to inet_pton',)
Request Method: GET
Request URL: http://localtest.com:8080/o/complete/facebook/?redirect_state=FG4K...UG1k
Django Version: 1.6.11
Exception Type: RuntimeError
Exception Location: /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/ext/remote_api/remote_api_stub.py in _MakeRealSyncCall, line 235
Python Executable: /usr/local/opt/python/bin/python2.7
Python Version: 2.7.11
Obviously FB is passing an approval back to my app, as the request URL includes the callback path.
It appears that something in the GoogleAppEngineLauncher is trying to look up an address and is not receiving the right data in? I'm not really sure.
In trying to resolve this, I've come across a single comment somewhere suggesting to a user that SimpleAuth might be a better way to go, but I don't understand why and I'm not really sure I want to start over if I am just missing something obvious.
Does anyone know why I am getting this error and what I can do to correct it?
It happens because the Facebook SDK depends on the awesome requests library. However, requests doesn't work on Google App Engine since the platform has some restrictions. You have to use their urlfetch APIs to fetch external contents on Google App Engine.
So yes, the official Facebook SDK won't work. You have to roll your own solution or find one that works. SimpleAuth is one of the solution that is known to have worked.
UPDATE: the original answer (starting with 'HOWEVER') is no longer necessary, just use requests 2.10.0 or above, urllib3 1.15.1 or above, and requests_toolbelt 0.6.2 or above and perform the following in your main():
from requests_toolbelt.adapters import appengine
appengine.monkeypatch()
HOWEVER if you're using older versions of requests and/or urllib3, then you need the patches below:
This can be accomplished using a patched version of requests along with the requests-toolbelt package. Threads that apply:
HTTPS not working on Google App Engine #1905
urllib3 / Contrib Modules / Google App Engine
Fixes the AppEngineManager to work within the requests framework #763
Add AppEngineAdapter for GAE users #114
Adds a monkeypatch() function that ensures all Sessions use the AppEngineAdapter compatibility class. #119
I've applied all of this and now have python-social-auth and facebook-sdk working in both local test (the dev server) and production (full App Engine).
In your vendored libraries, ensure that you have requests_toolbelt. (pip install -t lib requests_toolbelt). Then "monkeypatch" appengine support before python-social-auth ever calls requests. In my project/wsgi.py, I added the following lines:
from requests_toolbelt.adapters import appengine
appengine.monkeypatch()
python-social-auth depends on requests, so it should also exist in your vendor directory.
You must also ensure you are using requests version >= 2.10.0. This has not been released yet, so you can fake it. Edit lib/requests/__init__.py so that __build__ = 0x021000. You also must upgrade the packaged version of urllib3 in the lib/requests/packages/ directory to the latest version.
This is what worked for me.
There seem to be 2 ways to use django 1.1 with GAE
Google App Engine helper for django
The new use_library() function
We currently use the first. Should we switch? And what's the difference between the two?
use_library loads an unpatched version of django in the production environment, so many things will not work out of the box on app-engine.
The helper applies a series of patches to the django libraries to enable things like Sessions, test, cache framework, etc. If you do not add your own copy of django into your helper application and you are using the latest release (r100 or higher), the helper first tries to load django 1.1 and if it does not succeed then loads 1.0. You can see this in appengine_django/__init__.py::LoadDjango.
On production GAE, django 1.1 always exists, so it is loaded first.
However, on your development environment the dev server SDK does not distribute Django. Therefore, it uses whatever version of Django it can find, first trying 1.1 and then 1.0 and if it cannot find one then throws UnacceptableVersionError.
You probably want to use the helper and not use_library because then you will need to patch the raw django libraries yourself, thus duplicating the work in the helper. Whether you distribute your own version of django, either as a folder or zip file is up to you. One of the advantages of not distributing your own copy of django is that as google applies security patches you automatically get them without having to redeploy your application.
the replacement is called django-nonrel (and djangoappengine)... you can find it at
http://www.allbuttonspressed.com ... with django-nonrel, you should be able to run pure Django apps on top of App Engine without tweaking your models!
FYI, there is at least one more way to get Django 1.1 in GAE.
Take a look at http://code.google.com/p/app-engine-patch/
It allows use to use most of Django features including Admin.
app-engine-patch seems to have died:
http://code.google.com/p/app-engine-patch/issues/detail?id=253
As of GAE 1.5.0, there's a much simpler way of specifying a Django version.
In appengine_congif.py, include the line
webapp_django_version = '1.2'
This will cause the use_libary() to happen under the covers.
I wanted to check the status of running Django on the Google App Engine currently and what the benefits of running django on GAE over simply using Webapp.
Django main killer feature, IMHO, is the reuseable apps and middleware. Unfortunately, most current Django apps use models or model forms (django-tags, django-reviews, django-profiles, Pinax apps).
So what are the remaining features or benefits that django has that can still run in Google App Engine (other than what's disabled: the popular django apps, session and authentication middleware, users and admin, models, etc).
Also, is there a list of the Django apps that work in App Engine as well?
app-engine-patch currently has the most of django functional, including sessions, contrib.auth, sites, and some other standard django apps. However, its main drawback (my opinion) is that it uses a zip file of a modified version of django to achieve this functionality and the current maintainers don't seem to have kept pace with current django releases. Currently it seems to be the consensus of the past and present maintainers that this approach is too cumbersome to maintain and therefore no one is currently maintaining it.
google-app-engine-django, uses a monkey patch approach of the latest django version included in the production GAE runtime, so as long as google continues to track django releases you'll be kept up to date regarding django. However, it currently has not fully ported contrib.auth, so you can only authenticate with google accounts - which can be a big drawback depending on whether you want contrib.auth User models to work as you know them on sql backends. There is also no django admin support in the helper as there is in app-engine-patch. A fork of django-app-engine-django exists which adds in some of the contrib apps, such as flatpages, sites, and sitemaps. Also note, it only works on django versions up to 1.1, until issue #3230 Django 1.2 is added to use_library, unless you upload django as a zip file.
On the horizon, the original developer of app-engine-patch has been working on the django-nonrel branch, but this may be pretty far away from being included in a django release. This django developers thread has a lot of information about these efforts.
Separately, there is a google summer of code project working on integrating some aspects of nonrel db's.
app-engine-patch gets most of those things working inside AppEngine - so you can (mostly) use straight Modelforms, use the Django users and admin, etc.
I've only used it for fairly simple projects (being quite new to django), but they claim that most Django apps will work with (at most) minor modifications on appengine. For instance, app-engine-patch uses the AppEngine Model classes rather than the Django classes; and there are some of the basic views that are too inefficient to run on Appengine.
added: google-app-engine-django is similar; but provides a BaseModel that appears identical to Django's BaseModel. My understand is that google-app-engine-django was released by Google, then forked to create app-engine-patch. The maintainers of app-engine-patch seem to have some different goals from the creators of google-app-engine-django, so you may find that one of the two suits your needs better than the other.
Google have provided some articles on running Django apps on appengine; the most recent is actually a guest post from the authors of app-engine-patch.
I've had the best success by simply picking and choosing the Django features that I need and patching them into webapp myself. In my latest project I actually just cut out the webapp stuff entirely. I still import and call several webapp utility functions, but it is mostly a hand rolled application built from the good parts of GAE and Django.
You might be interested to check out web2py, another Python framework that supposedly has less friction between GAE and a "normal" web server.
It is now quite easy to use full Django on GAE:
https://developers.google.com/appengine/articles/django-nonrel#ps
The Django version provided with App Engine has been updated to 1.2.5 with the latest SDK release (1.4.2, changelog). This version is available through the use_library() declaration, so you no longer need to mess around with monkey patching to the same extent.
The GoogleAppEngine (GAE) Python 2.7 runtime provides several third-party libraries that your application can use, in addition to the Python standard library, GAE tools, and GAE Python runtime environment. One of them is Django. The below is copied from the GAE docs page on third-party libraries:
To use Django in Python 2.7, specify the WSGI application and Django library in app.yaml:
...
handlers:
- url: /.*
script: main.app # a WSGI application in the main module's global scope
libraries:
- name: django
version: "1.2"