issue_comments

I'm going to clean this up for consistency tomorrow morning so hold off merging until then please

On Tue, May 22, 2018 at 6:34 PM, Simon Willison notifications@github.com wrote:

Yeah let's try this without pysqlite3 and see if we still get the correct version.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/simonw/datasette/pull/280#issuecomment-391076458, or mute the thread https://github.com/notifications/unsubscribe-auth/AAihfMI-H6CBt-Py0xdBbH2xDK0KsjT2ks5t1EwYgaJpZM4UI_2m .

Alright, that should work now -- let me know if you would prefer any different behaviour.

Yeah let's try this without pysqlite3 and see if we still get the correct version.

This looks amazing! Can't wait to try this out this evening.

Sorry, just realised you rely on version being a module ...

I think I prefer the aesthetics of just "0.22" for the version string if it's a tagged release with no additional changes - does that work?

Yes! That's the default versioneer behaviour.

I'd like to continue to provide a tuple that can be imported from the version.py module as well, as seen here:

Should work now, it can be a two (for a tagged version), three or four items tuple.

``` In [2]: datasette.version Out[2]: '0.12+292.ga70c2a8.dirty'

In [3]: datasette.version_info Out[3]: ('0', '12+292', 'ga70c2a8', 'dirty') ```

```python

import sqlite3 sqlite3.sqlite_version '3.23.1'

``` running the above in the container seems to show 3.23.1 too so maybe we don't need pysqlite3 at all?

This is fantastic!

I think I prefer the aesthetics of just "0.22" for the version string if it's a tagged release with no additional changes - does that work?

I'd like to continue to provide a tuple that can be imported from the version.py module as well, as seen here:

https://github.com/simonw/datasette/blob/558d9d7bfef3dd633eb16389281b67d42c9bdeef/datasette/version.py#L1

Presumably we can generate that from the versioneer string?

Yup, I'll have a think about it. My current thoughts are for spatialite we'll need to hook into the following places:

• Inspection, so we can detect which columns are geometry columns. (We also currently ignore spatialite tables during inspection, it may be worth moving that to the plugin as well.)
• After data load, so we can convert WKB into the correct intermediate format for display. The alternative here is to alter the select SQL itself and get spatialite to do this conversion, but that strikes me as a bit more complex and possibly not as useful.
• HTML rendering.
• Querying?

The rendering and querying hooks could also potentially be used to move the units support into a plugin.

See also #278

The other reason I mention plugins is that I have an idea to outlaw JavaScript entirely from Datasette core and instead encourage ALL JavaScript functionality to move into plugins.right now that just means CodeMirror. I may set up some of those plugins (like CodeMirror) as default dependencies so you get them from "pip install datasette".

I like the neatness of saying that core Datasette is a very simple JSON + HTML application, then encouraging people to go completely wild with JavaScript in the plugins.

If we can't get import sqlite3 to load the latest version but we can get import pysqlite3 to work that's fine too - I can teach Datasette to import the best available version.

I think I can do this almost entirely within my existing BaseView class structure.

First, decouple the async data() methods by teaching them to take a querystring object as an argument instead of a Sanic request object. The get() method can then send that new object instead of a request.

Next teach the base class how to obey the ASGI protocol.

I should be able to get support for both Sanic and uvicorn/daphne working in the same codebase, which will make it easy to compare their performance.

That looks great. I don't think it's possible to derive the current commit version from the .zip downloaded directly from GitHub, so needing to pip install via git+https feels reasonable to me.

Right now the plugin stuff is early enough that I'd like to get as many potential plugin hooks as possible crafted out A much easier to judge if they should be added as actual hooks if we have a working branch prototype of them.

Some kind of mechanism for custom column display is already needed - eg there are columns where I want to say "render this as markdown" or "URLify any links in this text" - or even "use this date format" or "add commas to this integer".

You can do it with a custom template but a lower-level mechanism would be nicer.

This shipped in Datasette 0.22. Here's my blog post about it: https://simonwillison.net/2018/May/20/datasette-facets/

Useful GitHub code search: https://github.com/search?utf8=✓&q=%22libspatialite-4.4.0%22+%22RC0%22&type=Code

For SpatiaLite this example may be useful - though it's building 4.3.0 and not 4.4.0: https://github.com/terranodo/spatialite-docker/blob/master/Dockerfile