Datasette removes its retired Now deployment command
Datasette 0.40 removes the Now v1 publisher and directs Now v2 users to a plugin. It also accepts YAML metadata and fixes configuration handling during publishing.
A deployment command depends on a hosting platform whose lifecycle it does not control. Datasette 0.40 removes datasette publish now because the command targeted the retired Zeit Now v1 platform. Its April 22 release announcement directs users of Now v2 to a separate datasette-publish-now plugin. The change makes the platform dependency visible at the point where a publisher installs the integration.
This concerns a particular deployment path, not the ability to publish a SQLite database through Datasette. The publishing documentation in the release tag still describes built-in commands for Heroku and Google Cloud Run. It also describes packaging databases and the application into a Docker image. A retired platform integration can therefore leave the core tool without making the dataset itself obsolete.
I value SQLite's separation between the database file and the services around it. This release illustrates why that separation matters when data is published on someone else's infrastructure. A hosting platform can retire while the database remains useful, although the deployment machinery needs to change.
A replacement integration has its own installation
The release announcement identifies the removed command as a Now v1 integration and names the plugin as the route to Now v2. Those are different platform versions. Continuing to offer the old command would not by itself provide compatibility with the newer service. The removal tells users that their existing publishing instruction no longer describes a supported target.
Moving the integration into a plugin also changes where users obtain that functionality. The publishing documentation already presents Fly as a separately installed publishing plugin. The new Now arrangement follows the same general separation between the data-publishing application and an optional platform-specific adapter. This is a judgment about the documented packaging, not a claim that every integration now follows an identical lifecycle.
A publisher choosing another documented target can see its deployment operation directly. For Cloud Run, the release documentation gives the following form. The database name and service name are illustrative inputs.
datasette publish cloudrun mydatabase.db --service=my-database
The documented service name identifies a hosted application. Publishing to an existing service name replaces the previous deployment, so that argument has operational meaning beyond a descriptive label. The command also assumes that the appropriate cloud account and command-line tools have already been configured. A short publishing command does not eliminate those platform prerequisites.
The distinction matters when reading old deployment instructions. A database filename describes an input to the publishing operation, while the publisher subcommand selects external behavior. The SQLite file alone cannot establish whether an old hosting command remains usable. This release changes the supported command set because the external service changed.
Metadata gains an alternative representation
Version 0.40 also accepts metadata as YAML instead of requiring JSON. The tagged metadata documentation describes metadata at the instance, database and table levels. It can describe sources and licenses, and it supplies information Datasette displays around the dataset. YAML changes how the publisher writes that configuration, without changing the fact that it remains separate from the database rows.
For example, a publisher can give an instance a title and a description through a small metadata document. These values are illustrative, and the keys are the metadata fields documented by the release.
title: Published observations
description: Observations available for exploration and reuse.
source: Example collection
source_url: https://example.com/
The existing --metadata option supplies a metadata file when running Datasette. The new YAML support is optional, so existing JSON metadata does not need conversion merely to adopt this release. That compatibility is useful for deployment systems that already generate JSON, while allowing a publisher to maintain a YAML file where that is more convenient.
The metadata hierarchy also matters independently of serialization. A top-level source or license can describe the whole published collection, while database and table metadata can provide more specific information. Choosing YAML does not resolve an incorrect attribution or establish permission to redistribute data. It gives the same publishing configuration another documented representation.
Publishing must preserve plugin configuration
The announcement includes a fix for --plugin-secret overriding plugin configuration supplied in metadata.json. This is a concrete interaction between two inputs to a deployment operation. A publisher can provide ordinary plugin settings in metadata and supply secrets through a separate publishing option. Losing the ordinary settings while adding the secret makes the resulting deployment differ from the intended configuration.
I regard that preservation as part of the publishing interface's correctness. The deployment operation needs to carry the configured application to its destination, including the settings that are not secret. The release note describes a fix to that combination, without claiming that changing the hosting adapter alone would address it.
Taken together, the documented publishing behavior has several independently managed inputs. The database file provides the data, metadata describes the publication, and the selected publishing integration targets a hosting platform. In 0.40, YAML becomes another supported metadata representation while the retired Now v1 command leaves the built-in command set. Existing Now users need the integration for the platform version they actually intend to deploy to.