#232: Fix pycsw imports

[etj]

Fixes #232: ckan-pycsw is not compatible with recent pycsw versions

[amercader]

@etj can you check if we can pin the correct pycsw version in our pip-requirements.txt file? By that I mean if there's a conflict with the pycsw requirements and ours (if there is we should upgrade ours, unless they conflict with ckan core)

[etj]

@amercader The requirements file in pycsw do not have pinned versions.

At the moment on master branch (commit geopython/pycsw@777092b5), pycsw has the following dependencies (computed using pip-compile):

lib	pycsw	ckan	ckanext-harvest	ckanext-spatial
aenum	==2.2.1
certifi	==2019.9.11
chardet	==3.0.4
geolinks	==0.2.0
idna	==2.8
lxml	==4.4.1	>2.3
owslib	==0.18.0	0.8.6
psycopg2	==2.8.3	2.7.3.2
pyproj	==2.2.2
python-dateutil	==2.8.0	1.5
pytz	==2019.3	2016.7
requests	==2.22.0	2.11.1	2.20	>=1.1.0
shapely	==1.6.4.post2	>= 1.2.13
six	==1.12.0	1.11.0
sqlalchemy	==1.3.10	1.1.11
urllib3	==1.25.6
xmltodict	==0.12.0

[amercader]

OWSLib is the only thing that looks worrying, but I assume that you are running the latest version required by pycsw without problems? It looks like it's safer to let users install pycsw manually and solve any potential requirements conflicts themselves rather than pin it.

[etj]

Anyway I see that ckan-pycsw is only importing stuff from pycsw and nothing from ckan (since it uses the HTTP API). Maybe it could be easier to run it from within the pycsw virtualenv than from inside the ckan's one. First prob I saw (and then stopped trying that way) was that my pycsw was using a python3 interpreter, but the ckan-pycsw contains some constructs that are only valid in python2.7. I guess that once fixed that few errors it may be the way to go.