issues

• https://github.com/simonw/sqlite-utils/issues/344#issuecomment-982014776

Make table.transform() preserve STRICT mode.

:books: Documentation preview :books:: https://sqlite-utils--604.org.readthedocs.build/en/604/

The PR moves the following fields from metadata.yaml to datasette.yaml:

permissions allow allow_sql queries extra_css_urls extra_js_urls

This is a significant breaking change that users will need to upgrade their metadata.yaml files for. But the format/locations are similar to the previous version, so it shouldn't be too difficult to upgrade.

One note: I'm still working on the Configuration docs, specifically the "reference" section. Though it's pretty small, the rest of read to review

Part of #2093

In #2149 , we ported over "settings.json" into the new datasette.yaml config file, with a top-level "settings" key. This PR ports over plugin configuration into top-level "plugins" key, as well as nested database/table plugin config.

From now on, no plugin-related configuration is allowed in metadata.yaml, and must be in datasette.yaml in this new format. This is a pretty significant breaking change. Thankfully, you should be able to copy-paste your legacy plugin key/values into the new datasette.yaml format.

An example of what datasette.yaml would look like with this new plugin config:

```yaml

plugins: datasette-my-plugin: config_key: value

databases: fixtures: plugins: datasette-my-plugin: config_key: fixtures-db-value tables: students: plugins: datasette-my-plugin: config_key: fixtures-students-table-value

```

As an additional benefit, this now works with the new -s flag:

bash datasette --memory -s 'plugins.datasette-my-plugin.config_key' new_value

Marked as a "Draft" right now until I add better documentation. We also should have a plan for the next alpha release to document and publicize this change, especially for plugin authors (since their docs will have to change to say datasette.yaml instead of metadata.yaml

:books: Documentation preview :books:: https://datasette--2183.org.readthedocs.build/en/2183/

refs #2157

This PR adds a new --internal option to datasette serve. If provided, it is the path to a persistent internal database that Datasette core and Datasette plugins can use to store data, as discussed in the proposal issue.

This PR also removes and deprecates the previous in-memory _internal database. Those tables now appear in the internal database, with core_ prefixes (ex tables in _internal is now core_tables in internal).

A note on the new core_ tables

However, one important notes about those new core_ tables: If a --internal DB is passed in, that means those core_ tables will persist across multiple Datasette instances. This wasn't the case before, since _internal was always an in-memory database created from scratch.

I tried to put those core_ tables as TEMP tables - after all, there's always one 1 internal DB connection at a time, so I figured it would work. But, since we use the Database() wrapper for the internal DB, it has two separate connections: a default read-only connection and a write connection that is created when a write operation occurs. Which meant the TEMP tables would be created by the write connection, but not available in the read-only connection.

So I had a brillant idea: Attach an in-memory named database with cache=shared, and create those tables there!

sql ATTACH DATABASE 'file:datasette_internal_core?mode=memory&cache=shared' AS core;

We'd run this on both the read-only connection and the write-only connection. That way, those tables would stay in memory, they'd communicate with the cache=shared feature, and we'd be good to go.

However, I couldn't find an easy way to run a ATTACH DATABASE command on the read-only query.

Using Database() as a wrapper for the internal DB is pretty limiting - it's meant for Datasette "data" databases, where we want multiple readers and possibly 1 write connection at a time. But the internal database doesn't really require that kind of support - I think we could get away with a single read/write connection, but it seemed like too big of a rabbithole to go through now.

:books: Documentation preview :books:: https://datasette--2162.org.readthedocs.build/en/2162/

Just like the Datasette prepare_connection hook, this PR adds a similar hook for the sqlite-utils plugin system.

The sole argument is conn, since I don't believe a database or datasette argument would be relevant here.

I want to do this so I can release sqlite-utils plugins for my SQLite extensions, similar to the Datasette plugins I've release for them.

An example plugin: https://gist.github.com/asg017/d7cdf0d56e2be87efda28cebee27fa3c

```bash $ sqlite-utils install https://gist.github.com/asg017/d7cdf0d56e2be87efda28cebee27fa3c/archive/5f5ad549a40860787629c69ca120a08c32519e99.zip

$ sqlite-utils memory 'select hello("alex") as response' [{"response": "Hello, alex!"}] ``` Refs: - #574

:books: Documentation preview :books:: https://sqlite-utils--573.org.readthedocs.build/en/573/

This also passes in the extension path when specified in GIS methods. Wherever we know an extension path, we use db.init_spatialite(find_spatialite() or load_extension).

:books: Documentation preview :books:: https://sqlite-utils--531.org.readthedocs.build/en/531/

I haven't tested this yet but wanted to get a heads-up whether this kind of change would be useful or if I should just duplicate the function and tweak it within my code

:books: Documentation preview :books:: https://sqlite-utils--480.org.readthedocs.build/en/480/

Work in progress, partly to test the ReadTheDocs preview link action.

Refs: - #426

:books: Documentation preview :books:: https://readthedocs-preview--460.org.readthedocs.build/en/460/

Updates the requirements on janus to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Refs #511

Refs #1305

• compact dict and set building
• remove redundant parentheses
• simplify chained conditions
• change method name to lowercase
• use triple double quotes for docstrings

please feel free to accept/reject any of these independent commits

• [x] Remove the /-/...blob/... route I added in #1040 in place of the new .blob renderer URLs
• [x] Link to new .blob download links on the arbitrary query page (using _blob_hash=...) - plus tests for this

Closes #1050, Closes #1051

To handle packages that require Javascript state setting prior to loading a package (eg thebelab, provide a template block before the URLs are loaded.

Hi, thanks for datasette!

This PR adds the LICENSE to source distributions, which seems the norm for Apache-2.0 stuff.

I noticed the 0.50.2 sdist doesn't ship LICENSE, but the 0.5.2 whl does, so I'm assuming the intent is to ship... and it's a one-liner!

Motivation:

It might be a bit of a slog, but I'm looking to see about getting datasette (and friends!) available on conda-forge. There are a few missing upstreams (asgi-csrf, python-basecov, mergedeep) and some of the plugins don't even appear to have tarballs (just whl!), but the little stuff like licenses are nice to get out handled upstream vs separately grabbing them.

Refs #787. Will need quite a bit of manual testing since this involves code which runs against Heroku and Cloud Run.

Refs #648. TODO: - [x] Pass a view_name to render_template() - [x] Mechanism for custom status code / headers / redirect - [x] Documentation

This adds the option for a user to set up triggers in the database to keep their FTS table in sync with the parent table.

Ref: https://sqlite.org/fts5.html#external_content_and_contentless_tables

I would prefer to make the creation of triggers the default behavior, but that will break existing usage where people have been calling populate_fts after inserting new rows.

I am happy to make changes to the PR as you see fit.

While debugging why my static mounts using a relative path (--static mystatic:rel/path/to/dir) not working, I noticed that the requests fail no matter what, returning 404 errors.

The reason is that datasette tries to prevent traversal exploits by checking if the path is relative to its registered directory. This check fails when the mount is a relative directory, because /abs/dir/file obviously not under dir/file.

https://github.com/simonw/datasette/blob/81fa8b6cdc5457b42a224779e5291952314e8d20/datasette/utils/asgi.py#L303-L306

This also has the consequence of returning any requested file, because when /abs/dir/../../evil.file resolves aiofiles happily returns it to the client after it resolves the path itself. The solution is to make sure we're checking relativity of paths after they're fully resolved.

I've implemented the mentioned changes and also updated the tests.

WIP for #427

I think that's all for getting Versioneer support, I've been happily using it in a couple of projects ...

In [2]: datasette.__version__ Out[2]: '0.22+3.g6e12445' Repo: https://github.com/warner/python-versioneer

Versioneer Licence: Public Domain (CC0-1.0)

Closes #273

Is this what you had in mind for this issue?