Fails to retrieve libspatialite after it went 4.0

[GoogleCodeExporter]

What steps will reproduce the problem?
1. pip install pyspatialite

What is the expected output? What do you see instead?

Expectation is that the package is installed succesfully. Instead the build 
fails because it can't find the libspatialite-amalgamation archive:

 File "/home/otimperi/venv/build/pyspatialite/setup.py", line 97, in get_amalgamation

    download_file = pattern.findall(download_page)[0]

IndexError: list index out of range

What version of the product are you using? On what operating system?

Version 3.0.1, the one currently available in PyPI.

Please provide any additional information below.

I attached a patch that should fix the problem.

Original issue reported on code.google.com by timp...@gmail.com on 27 Nov 2012 at 10:32

[GoogleCodeExporter]

Hmm. The attachment was not included for some reason?

Original comment by timp...@gmail.com on 27 Nov 2012 at 10:34

Attachments:

• fix_3.0.1_build_after_libspatialite_introduced_version_4.0.patch

[GoogleCodeExporter]

This issue deserves attention because as things stand currently, pyspatialite 
cannot be installed via pip on any new projects.

Original comment by emac...@gmail.com on 8 Feb 2013 at 12:17

[GoogleCodeExporter]

Browsing an url is not robust - this will fail again next time the URL is 
changed. setup.py should not try to be smart on this and the project should 
either release the file either raise if the lib is not installed -- and explain 
what to install

Original comment by ziade.ta...@gmail.com on 29 May 2013 at 2:19

[GoogleCodeExporter]

Hosting our own copy of the file may be the best solution, as the site 
structure does change on a regular basis.

If anyone has suggestions on how to support multiple versions of spatialite 
within this single project, it'd be appreciated - most people don't want to 
move beyond 3 currently, for compatibility reasons.

Original comment by lok...@gmail.com on 29 May 2013 at 2:40

• Changed state: Accepted

[GoogleCodeExporter]

Won't you please fix this?  I'd rather use this over pysqlite, but I manage the 
rest of my projects with pip, so I'm not about to build this from source when I 
can just use pysqlite...

I agree that setup.py shouldn't try to be smart.  I noticed that the patch not 
only uses a different URL, but chooses the last element instead of the first, 
implying that the sorting also changed when the index page changed.  With 
multiple moving parts, I'd much rather see a "dumb" setup.py -- my suggestion 
would be to just hard-code a stable URL into the script.

Original comment by maackl...@gmail.com on 19 Aug 2013 at 4:41

[GoogleCodeExporter]

What's going on here, will it ever be possible to pip install pyspatialite?

There is a problem installing the previous version too:

$ pip install pyspatialite==2.6.2-spatialite.2.4.0-4

try and use it:

  File "/Users/paul/Documents/Dev/Personal/pgb/.venv/lib/python2.7/site-packages/pyspatialite/dbapi2.py", line 50, in <module>
    version_info = tuple([int(x) for x in version.split(".")])
ValueError: invalid literal for int() with base 10: '2-spatialite'

hmm, pyspatialite can't recognise its own version number. awesome

Original comment by bluesk...@gmail.com on 27 Oct 2013 at 2:31

[GoogleCodeExporter]

I'll try and get around to working on pyspatialite again in the next week or so.
Still conceptually having a problem figuring out how to handle multiple 
versions of spatialite - sometimes, people want 2.x, or 3.x, or now even 4.x.
Any other python packages that support multiple versions of a library?  How do 
they handle the problem?

Original comment by lok...@gmail.com on 27 Oct 2013 at 4:23

[GoogleCodeExporter]

You might check to see if GDAL does anything to handle different libgdal 
versions.  Otherwise, it might be easiest to have three separate code bases: 
pyspatialite2, pyspatialite3, and pyspatialite4.  You could then have 
pyspatialite contain code that is non version specific to avoid duplicating 
code.

Best,

Brian

Original comment by selimna...@gmail.com on 27 Oct 2013 at 6:13

[GoogleCodeExporter]

Amalgamation went away after version 3.0.1, so a new approach will have to be 
done.

I'm moving the repository over to github, for more community involvement, and 
after fixing for 3.0.1, I'll be looking for solutions for 4.x.  I think 
switching to dynamic linking and Cython may be the best option; we'll see.

Original comment by lok...@gmail.com on 21 Nov 2013 at 10:27

[GoogleCodeExporter]

Issue 10 has been merged into this issue.

Original comment by lok...@gmail.com on 21 Nov 2013 at 10:27

[GoogleCodeExporter]

Issue 11 has been merged into this issue.

Original comment by lok...@gmail.com on 21 Nov 2013 at 10:28

[GoogleCodeExporter]

Issue 12 has been merged into this issue.

Original comment by lok...@gmail.com on 21 Nov 2013 at 10:28