Opened 9 years ago
Closed 9 years ago
#25011 closed Cleanup/optimization (fixed)
Running unit tests on Mac takes me down a GDAL installation rabbit hole
Reported by: | Ned Batchelder | Owned by: | nobody |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I wanted to run the unit tests on my Mac. I followed the instructions:
[:/src/django/nedbat/tests] master ± mkvirtualenv django New python executable in django/bin/python Installing setuptools, pip...done. [:/src/django/nedbat/tests] [django] master ± pip install -r requirements/py2.txt ... many lines elided ... Successfully installed bcrypt docutils jinja2 numpy Pillow PyYAML pytz selenium sqlparse python-memcached mock cffi six markupsafe pycparser Cleaning up... [:/src/django/nedbat/tests] [django] master ± PYTHONPATH=..:$PYTHONPATH ./runtests.py Testing against Django installed in '/src/django/nedbat/django' Traceback (most recent call last): File "./runtests.py", line 435, in <module> options.debug_sql) File "./runtests.py", line 239, in django_tests state = setup(verbosity, test_labels) File "./runtests.py", line 218, in setup apps.set_installed_apps(settings.INSTALLED_APPS) File "/src/django/nedbat/django/apps/registry.py", line 318, in set_installed_apps self.populate(installed) File "/src/django/nedbat/django/apps/registry.py", line 108, in populate app_config.import_models(all_models) File "/src/django/nedbat/django/apps/config.py", line 198, in import_models self.models_module = import_module(models_module_name) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py", line 37, in import_module __import__(name) File "/src/django/nedbat/tests/gis_tests/models.py", line 10, in <module> from django.contrib.gis.db import models File "/src/django/nedbat/django/contrib/gis/db/models/__init__.py", line 5, in <module> from django.contrib.gis.db.models.aggregates import * # NOQA File "/src/django/nedbat/django/contrib/gis/db/models/aggregates.py", line 1, in <module> from django.contrib.gis.db.models.fields import ExtentField File "/src/django/nedbat/django/contrib/gis/db/models/fields.py", line 4, in <module> from django.contrib.gis.gdal.raster.source import GDALRaster File "/src/django/nedbat/django/contrib/gis/gdal/raster/source.py", line 6, in <module> from django.contrib.gis.gdal.driver import Driver File "/src/django/nedbat/django/contrib/gis/gdal/driver.py", line 5, in <module> from django.contrib.gis.gdal.prototypes import ds as vcapi, raster as rcapi File "/src/django/nedbat/django/contrib/gis/gdal/prototypes/ds.py", line 9, in <module> from django.contrib.gis.gdal.libgdal import lgdal File "/src/django/nedbat/django/contrib/gis/gdal/libgdal.py", line 45, in <module> '", "'.join(lib_names)) django.contrib.gis.gdal.error.GDALException: Could not find the GDAL library (tried "gdal", "GDAL", "gdal1.11.0", "gdal1.10.0", "gdal1.9.0", "gdal1.8.0", "gdal1.7.0"). Try setting GDAL_LIBRARY_PATH in your settings.
A quick look at how to install gdal lead to scary pages, and a requirement to install GEOS, etc.
Looking at tests/gis_tests/models.py, it looks like it's trying to neuter itself if the GIS requirements aren't installed, but I guess it isn't doing it well enough?
I'd be glad to hack on making this better if someone could guide me on the philosophy to follow.
Change History (10)
comment:1 by , 9 years ago
Triage Stage: | Unreviewed → Accepted |
---|---|
Version: | 1.8 → master |
comment:2 by , 9 years ago
Here is a possible solution, I think the RasterField needs to be imported separately from the geometry fields, as it depends on gdal but the geom fields can be used with only geos as well. So the proposed patch splits the GIS fields modlue in submodules.
comment:3 by , 9 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Let's just reference the original ticket (#23804) when committing this.
comment:4 by , 9 years ago
You've marked this ticket as a duplicate of a closed ticket? What will track the work to fix the problem?
comment:5 by , 9 years ago
We could reopen the original ticket, but don't worry, the pull request won't get lost.
comment:7 by , 9 years ago
Replying to nedbat:
I didn't make a pull request for this...?
Tim is talking about https://github.com/django/django/pull/4905
comment:8 by , 9 years ago
It's not a big deal, and I'm sure it's true that the PR won't get lost, but I think Ned is right, and there wasn't a good reason to close this ticket as a duplicate (especially as a duplicate of a ticket it clearly isn't a duplicate of - "problem caused by fix for some other ticket" is not the same thing as "duplicate").
If there's a known problem in master (which there is right now), a ticket with a clear description of that problem (which this is) should be left open until a fix for the problem is merged to master. And that fix should reference the ticket which is a clear description of the problem it's fixing (and perhaps also the original ticket whose fix caused the problem in the first place.)
comment:9 by , 9 years ago
Resolution: | duplicate |
---|---|
Status: | closed → new |
Oops, that broke in a patch committed yesterday. I'll ping the author and ask him to take a look.