Python 2.5 and sqlite

["Martin v. Löwis"]

> If you think making a distinction between the SQLite package and the 
> libsqlite package is pedantic - I don't have a problem with that.

I think that is not only pedantic - it is also inaccurate. There is
no SQLite package, nor is there a libsqlite package, in the bigger+
world. From

  http://www.sqlite.org/download.html

I can download the following pieces:

  sqlite3-x.y.z.bin.gz (for Linux, likewise for OSX and Windows)
  tclsqlite3* (Tcl bindings - clearly irrelevant here)
  sqlite-x.y.z.so.gz (for Linux, likewise for Windows)
  sqlite3_analyzer-x.y.z (also clearly irrelevant here)
  sqlite-amalgation-x.y.z (amalgated sources)
  sqlite-x.y.z (complete sources, in tar.gz and .zip)

So there is no SQLite download, nor is there a libsqlite download.

I don't know what specific packages you are talking about - probably
about the way your Linux distribution choses to package things.

> Fact 
> is that none of the packages are required for using sqlite3 with Python 
> - they are only required when you want to compile Python yourself or 
> when Python uses the shared library.

So the shared library *is* required (as that is the typical way in which
SQLite is built)

> And even if you want to compile Python yourself, SQLite doesn't have to 
> be _installed_. You simply can dump the files wherever you like and
> point Python to it. This is often necessary on a machine where you 
> cannot install anything to the default locations because you don't have 
> admin rights.

And that is nit-picking. You don't have to do the "make install" step,
but I would suggest to do that, anyway, even on a machine where
you don't have admin rights. You just pass --prefix to the configure
of the amalgamated sources. This puts sqlite nicely into bin, include,
and lib directories, so that Python's setup.py can find it easier.

Regards,
Martin