You’re installing GeoDjango and you meet this error “django.core.exceptions.ImproperlyConfigured: Could not import user-defined GEOMETRY_BACKEND “geos” while trying to runserver (or any other command) in your project. Check the following in order of severity:
Have you included this in your .bash_profile (or equivalent)
Where 91 is the version of postgres you’re using.
If that doesn’t work, I would try reinstalling all the packages listed here: https://docs.djangoproject.com/en/dev/ref/contrib/gis/install/#macports
Make sure you’re getting the right versions for each package and that postgis is installing to the right postgres!
Ran into a day and half’s worth of trouble while trying to install postgis and I still haven’t resolved it yet. Some things to note so far:
- If you install postgis via brew, `brew install postgis`, it will also automagically install postgresql9.2.1 for you. So if you have a previous version of postgresql installed, you will now have 2!
- Django1.4 doesn’t play will with postgis2.0 for now. So, you have to install postgis1.5 (https://code.djangoproject.com/ticket/16455)
- postgis1.5 doesn’t play well with postgresql9.2.1, so you to install postgresql9.1.x (http://trac.osgeo.org/postgis/wiki/UsersWikiPostgreSQLPostGIS)
- So, the working versions to use together would be Django1.4.x with postgis1.5 and postgres9.1.x
- To NOT get the latests version of postgres from brew, follow this gist (https://gist.github.com/3188632) to install postgres9 which will link you to postgres9.08
- The crazy thing is trying to `brew install postgis15` gives me the following error 
- Client version of psql is different from the server version of postgres. If you run psql in terminal and you see something like `psql (9.2.1)`, it means the client and server versions are the same. If you see something like `psql (Client (9.2.1) Server (9.1.2))` (can’t remember the exact phrasing but the first number would be the client, the second number would be the server itself), it means the client and server versions are different.
- If you have a previous version of postgres, you would have had to run `initdb /usr/local/var/postgres`. You gotta move/delete this guy if you’re installing a new version of postgres and rerun the initidb command!
- `brew doctor` is your friend
Error in Question:
nai@nyc ~ $ brew install postgis15
==> Downloading http://postgis.refractions.net/download/postgis-1.5.3.tar.gz
Already downloaded: /Users/nai/Library/Caches/Homebrew/postgis15-1.5.3.tar.gz
==> ./configure –with-projdir=/usr/local –with-pgconfig=/usr/local/Cellar/postgresql/9.2.1/bin/pg_config
num2_tuples = reltup->reltuples;
4 errors generated.
make: *** [lwgeom_estimate.o] Error 1
make: *** [postgis] Error 2
Other Useful Links
brew uninstall postgresql –force
The internet has been abuzz on Apple’s recent patent war. My stance on this has always been that as a public listed company, Apple owes a fiduciary duty to maximise returns to its stakeholder and wielding the patent sword is just one of the many tools powerful companies have at their employ. Don’t blame the player, blame the (broken) game.
We can debate the merits and flaws of the existing patent system but that’s well covered. Perhaps, a more interesting question to ask is why has Apple taken such an provocative stance when it could have chosen to adopt a defensive posture instead?
When you have a company that’s built around a product visionary, and when many people are dependent on this person, the stakes are incredibly high. I imagine, as part of a ‘risk reduction strategy’, that the C-Suite executives have been planning for a scenario where Steve Jobs might no longer be with the company, be it for natural causes or not. Deepening the moats through patent protection is a good method to stall while they scramble to find the next Steve Jobs. Paul Graham said that he spoke to someone ‘high level’ at Apple and asked if there’s any more ground breaking products in the pipeline — the answer was: no. I suspect that a side result of this is that Apple will start using it’s massive cash reserve and go on an acquisition spree to try and find the next product visionary.
Faced with such a predicament, the most rationale decision management can make is to protect the company’s interests at all cost and milk the cow for all it’s worth while they can. Apple has at most 2 -3 cycles of products ahead of them that have been in planning for many years now. After which I imagine, they are going to plateau and their growth numbers are going to decline. They are going to be cruising at a steady state, reaping the harvest sown by Steve Jobs. So bring on the patent wars, Apple has a fort to defend.
from django.core.management.base import BaseCommand
from django.conf import settings
This counts the code for each app in the project and displays the
lines of code of unit test written.
help = 'Display Project Code Count and Unit Test Code count'
def handle(self, *args, **options):
file_types = ['views.py', 'forms.py', 'models.py', 'utils.py', 'tests.py']
counter = 0
unit_test_counter = 0
for app in settings.APPS:
for file_type in file_types:
file_name = app + '/' + file_type
with open(file_name) as f:
for row in f:
counter += 1
if file_type == 'tests.py':
unit_test_counter += 1
print 'Total lines of code in bbox only apps: %s' % counter
print 'Total lines of code in bbox excluding tests: %s' % (counter - unit_test_counter)
print 'Total lines of code in bbox tests: %s' % unit_test_counter
print 'For every 1 line of code written, %s lines of test code is written' \
% (float(counter-unit_test_counter) / float(unit_test_counter))
Total lines of code in project specific apps: 20172
Total lines of code in excluding tests: 13145
Total lines of code in tests: 7027
For every 1 line of code written, 1.87064181016 lines of test code is written