Documentation: https://docs.datasette.io/en/latest/plugins.html#seeing-what-plugins-are-installed

I'm going to have it only return plugins with a version other than None.

Problem - if there are plugins in the plugins directory it was returning this: messages_output_renderer.py==None my_plugin.py==None my_plugin_2.py==None register_output_renderer.py==None sleep_sql_function.py==None view_name.py==None

As part of this I'd like to refactor the JSON renderer code - I started attempting that here: https://github.com/simonw/datasette/commit/f3944608cc000a2542b4fe9a7a89c866391924f2

In particular I want to get rid of that data argument.

I'm going with a bit of a hacky workaround for the moment, until I get a chance to refactor this: - #2137

I made an initial attempt at this in a branch, but it broke too much other stuff. https://github.com/simonw/datasette/commit/f3944608cc000a2542b4fe9a7a89c866391924f2

Need ?_extra=columns too since I'm removing "columns" from the default query JSON in https://github.com/simonw/datasette/issues/2136

I'll make ?_extra=columns work in: - #2113

It also bothers me that ok comes first in one but not first in the other - I'd like the order of keys in the JSON to be consistent, even though order isn't meant to mean anything.

OK, I've done the small changes - still need to document the big JSON changes though.

Those aren't covered by the regular documentation either so I need to update that.

Updated documentation: https://docs.datasette.io/en/latest/plugin_hooks.html#render-cell-row-value-column-table-database-datasette-request

• Dropped support for Python 3.7
• New Justfile

• 1970

• datasette.render_template() now accepts a Context subclass as an alternative to a dictionary

• 2106

• 2007

• https://github.com/simonw/datasette/issues/2130
• https://github.com/simonw/datasette/issues/2079
• https://github.com/simonw/datasette/issues/1153

Remember not to include changes from this:

https://github.com/simonw/datasette/blob/26be9f0445b753fb84c802c356b0791a72269f25/docs/changelog.rst?plain=1#L9-L31

Punting this out of the 1.0a3 alpha for the moment.

Plugin configuration itself currently lives in metadata.json which I don't like - that file was supposed to be for metadata about your databases, it's a bit of an accident that it grew configuration options as well.

I'm hoping to fix that for Datasette 1.0, but I'm still figuring out how to do that.

Honestly the --all option isn't particularly useful - it's really more of a debugging tool for myself than something that I expect anyone else to use.

The purpose of datasette plugins generally is to help people confirm that plugins installed correctly. It's effectively the CLI alternative to hitting https://datasette.io/-/plugins

Yes, using this approach(datasette install -r requirements.txt) will result in more consistency.

I'm curious about the results of the datasette plugins --all command. Where will we use the output of this command? Will it include configuration information for these plugins in the future? If so, will we need to consider the configuration of these plugins in addition to installing them on different computers?

```diff diff --git a/datasette/cli.py b/datasette/cli.py index 32266888..370b722c 100644 --- a/datasette/cli.py +++ b/datasette/cli.py @@ -223,15 +223,22 @@ pm.hook.publish_subcommand(publish=publish)

@cli.command() @click.option("--all", help="Include built-in default plugins", is_flag=True) +@click.option( + "--requirements", help="Output requirements.txt of installed plugins", is_flag=True +) @click.option( "--plugins-dir", type=click.Path(exists=True, file_okay=False, dir_okay=True), help="Path to directory containing custom plugins", ) -def plugins(all, plugins_dir): +def plugins(all, requirements, plugins_dir): """List currently installed plugins""" app = Datasette([], plugins_dir=plugins_dir) - click.echo(json.dumps(app._plugins(all=all), indent=4)) + if requirements: + for plugin in app._plugins(): + click.echo("{}=={}".format(plugin["name"], plugin["version"])) + else: + click.echo(json.dumps(app._plugins(all=all), indent=4))

@cli.command() Output: % datasette plugins --requirements
datasette-codespaces==0.1.1 datasette-graphql==2.2 datasette-json-html==1.0.1 datasette-pretty-json==0.2.2 datasette-x-forwarded-host==0.1 ```

Neat idea! We already have this command:

datasette install -r requirements.txt

So maybe datasetet plugins --requirements could generate a requirements.txt file which could be used there.

Another place that needs fixing: https://github.com/simonw/datasette/blob/26be9f0445b753fb84c802c356b0791a72269f25/datasette/views/database.py#L244-L249

Alternatively, what about if there was a custom SQL function available during canned write queries for setting the output message? Then the fact that canned queries don't return a table view wouldn't be a problem. Bit weird though.

Annoying thing about this plugin is that you don't see the new counter value when you submit the increment or decrement query.

Maybe canned queries should support SQL multiple statements? Could return the result of the last one.

Here's a simple plugin that can do this: ```python from datasette import hookimpl

@hookimpl def startup(datasette): db = datasette.add_memory_database("counters")

async def inner():
    await db.execute_write("create table if not exists counters (name text primary key, value integer)")
    await db.execute_write("insert or ignore into counters (name, value) values ('counter', 0)")

return inner

@hookimpl def canned_queries(database): if database == "counters": return { "increment": { "sql": "update counters set value = value + 1 where name = 'counter'", "write": True, }, "decrement": { "sql": "update counters set value = value - 1 where name = 'counter'", "write": True, }, } ```

I decided to figure out where the _size= parameter here comes from: https://github.com/simonw/datasette/blob/cd57b0f71234273156cb1eba3f9153b9e27ac14d/datasette/views/database.py#L576-L588

It took some spelunking, but it looks like I added that five years ago as part of CSV streaming in https://github.com/simonw/datasette/commit/fc3660cfad7668dbce6ead12766e048fc1f78b11

It's there purely to allow CSV streaming to set _size="max".

And since CSV streaming is still just a table thing, not a query thing, I can drop it.