Skip to main content

Update-time - it's time to update your dependencies

Keeping dependencies up-to-date is an important aspect of software maintenance. Update-time is a command line tool that scans your repository for dependencies and updates them to their latest versions. It looks at the files you already have — pyproject.toml, hand-written requirements.txt files, package.json, Dockerfiles, GitHub Actions workflows, CircleCI configs, GitLab CI configs, Docker Compose and Helm manifests, devcontainer configs, and jsDelivr URLs — and rewrites the pinned versions in place. To avoid adopting freshly published releases that may still be buggy, it applies a cooldown period (see Cooldown below).

Usage

Run Update-time without installing it using uvx:

uvx update-time

Or install it as a uv tool so it's always available on your PATH:

uv tool install update-time
update-time

Update-time has a small command-line interface. Run update-time -h/--help to see all options, update-time -V/--version to print the version, update-time --cooldown DAYS to override the default cooldown period (see Cooldown below), and update-time --log-level LEVEL to set how much is logged (one of DEBUG, INFO, WARNING, ERROR; defaults to INFO). Available new versions are logged at INFO, so use --log-level WARNING to see only genuine problems, or --log-level DEBUG to also see which files are checked. All logging goes to standard error, leaving standard output for the --version and --help text. Running update-time with no options in the root folder of a repository updates all supported dependencies.

Update-time exits with status 0 when it ran (whether or not it changed any files), 2 when the command-line arguments are invalid, and a non-zero status when an updater could not complete. The exit status does not indicate whether anything was updated — inspect the diff (or the INFO-level log) for that.

The recommended workflow is to run Update-time on a dedicated branch, push it, and let CI do the verification:

  1. Create a branch for the updates.
  2. Run update-time in the root of your repository to update the dependencies in place.
  3. Commit the changes and open a pull request.
  4. Let your tests and checks run in CI to confirm nothing is broken before merging.

To raise API rate limits while updating, set the following environment variables before running Update-time:

  • GITHUB_TOKEN — increases the GitHub API rate limit when updating GitHub Actions. The token only needs to read public release and commit data, so no specific scope is required: both a classic token with no scopes selected and a fine-grained token with default read-only access to public repositories work.
  • DOCKER_HUB_USERNAME and DOCKER_HUB_TOKEN — authenticate to the Docker Hub API (both must be set) to increase its rate limit when updating Docker images.

What is updated

Update-time runs a set of updater scripts, each responsible for one kind of dependency. The file-rewriting scripts run concurrently where it's safe to do so; package.json engine and dependency updates run sequentially because they touch the same files.

Dependency Files Source
Python dependencies pinned with == pyproject.toml PyPI
Python dependencies pinned with == hand-written requirements*.txt, requirements/*.txt PyPI
npm and pnpm dependencies package.json (and package-lock.json / pnpm-lock.yaml) npm registry
Node engine version package.json the Node base image in the project's Dockerfile
Dockerfile base images (tag + digest) Dockerfile, *.Dockerfile, Dockerfile.* OCI registries (Docker Hub, ghcr.io, mcr.microsoft.com, …)
CircleCI images (tag + digest) CircleCI YAML configs OCI registries (Docker Hub, ghcr.io, mcr.microsoft.com, …)
GitLab CI images (tag + digest) .gitlab-ci.yml OCI registries (Docker Hub, ghcr.io, mcr.microsoft.com, …)
Docker Compose and Helm images (tag + digest) Compose files and Helm folder OCI registries (Docker Hub, ghcr.io, mcr.microsoft.com, …)
Devcontainer image and features (tag + digest) .devcontainer/devcontainer.json, .devcontainer.json OCI registries (ghcr.io, mcr.microsoft.com, Docker Hub, …)
GitHub Action versions (SHA + tag) workflow YAML files GitHub releases API
jsDelivr npm URLs (version + SRI hash) Sphinx config npm registry

Only versions specified with an exact match (== for Python, a concrete tag — optionally already pinned as tag@sha256:digest — for images) are updated; looser version specifiers are left untouched, so you can pin a maximum version to opt a dependency out of automatic updates. Where available, Update-time prints the changelog entries between the current and new version so you can review what changed.

In requirements.txt files only exact == pins are updated. The following are left untouched:

  • Git, VCS, and URL dependencies (e.g. git+https://github.com/org/repo.git@v8.0.3.0, direct URLs, and -e/editable installs) — these are not registry versions, so Update-time does not bump their refs; update them manually.
  • Compiled or hash-pinned files — a requirements.txt generated by pip-tools or uv pip compile (recognised by an autogenerated header, a sibling .in file, or --hash= lines) is skipped entirely, because bumping a single pin without recompiling its transitive dependencies and hashes would corrupt the file. Regenerate these with your compiler instead.

References that are not yet pinned are pinned automatically:

  • Docker images referenced by tag only — base images in Dockerfiles (FROM image:tag), CircleCI images, GitLab CI images, Docker Compose / Helm manifest images, and devcontainer base images and features — get the @sha256:digest of the (latest) tag appended, so the image is reproducible. The image's registry is taken from the reference, so images on Docker Hub and on other OCI registries (ghcr.io, mcr.microsoft.com, …) are both resolved; the cooldown, however, only applies to Docker Hub, since the OCI protocol exposes no publication date. Images without a concrete version tag are ignored: references through a template ({{ ... }}) or variable substitution (${VAR}), and tagless base images such as FROM scratch or stage references. CircleCI machine-executor images (the image: under a machine: key, such as ubuntu-2204:2024.01.1) are also left alone, since they are not registry images.
  • GitHub Actions referenced by version tag only (e.g. uses: actions/checkout@v4) are pinned to the commit SHA of the latest version, with the version added as a trailing comment (e.g. uses: actions/checkout@<sha> # v4.1.1). Actions referenced by a branch (e.g. @main) are left untouched because they don't resolve to a version.

Excluding a reference from updates

To stop Update-time from changing a specific reference — because of a known incompatibility, a deferred migration, or to keep something reproducible — add an # update-time: ignore comment (all lower-case). The reference is then left untouched and no registry or source is queried for it. You can add a reason after the marker, for example # update-time: ignore (pinned until the 3.13 migration).

The marker can be placed two ways:

  • Inline, on the reference's own line (in YAML files, requirements.txt, and — with a // comment — devcontainer.json):

    image: python:3.12  # update-time: ignore
    
    humanize==4.15.0  # update-time: ignore
    
    "ghcr.io/devcontainers/features/node:1": {}  // update-time: ignore
    
  • On the line directly above the reference. Use this form in Dockerfiles, which don't allow inline comments:

    # update-time: ignore
    FROM ghcr.io/astral-sh/uv:python3.12-bookworm-slim
    

This works for every reference Update-time rewrites line by line: Dockerfiles, Docker Compose and Helm manifests, CircleCI and GitLab CI configs, GitHub Actions workflows, devcontainer.json files, and requirements.txt files. Use a # comment everywhere except devcontainer.json (which is JSONC), where the marker goes in a // comment. An inline marker pins only its own line, so it never accidentally pins the reference on the line below it.

Run with --log-level DEBUG to see each ignored reference logged and confirm a marker is recognised. Since the marker is case-sensitive, a typo (or wrong case) simply produces no such log and the reference is updated as usual.

For pyproject.toml and package.json — which are updated through uv, npm, and pnpm rather than line by line — the marker does not apply. Opt a dependency out there by pinning it with a maximum or non-== version specifier instead (for example package<=3.12). The marker likewise has no effect on jsDelivr URLs, which are rewritten through a whole-file substitution rather than the line-by-line engine; there is currently no way to exclude a specific jsDelivr URL from updates.

Cooldown

To avoid adopting releases that are too fresh to trust, Update-time honours a cooldown period during which newly published versions are not yet picked up. It defaults to 7 days and can be changed with the --cooldown option, for example update-time --cooldown 14. How the cooldown is applied depends on the dependency type:

  • Docker images, GitHub Actions, requirements.txt dependencies, and jsDelivr npm URLs — Update-time enforces the cooldown itself, based on each image tag's push date and each release's publication date.
  • npm dependencies — Update-time passes the cooldown to npm via npm's min-release-age option (also measured in days), which npm added in 11.10.0; older npm versions ignore the option, so updates still run but without a cooldown. If your project already configures a cooldown in its .npmrc (min-release-age or before), Update-time leaves that in place instead of overriding it.
  • pnpm dependencies — Update-time passes the cooldown to pnpm via pnpm's minimumReleaseAge setting, converting the value to minutes (pnpm measures the age in minutes rather than days). If your project already configures minimumReleaseAge (in pnpm-workspace.yaml), Update-time leaves that in place instead of overriding it.
  • pyproject.toml dependencies — Update-time passes the cooldown to uv via uv's exclude-newer setting. If your pyproject.toml already sets exclude-newer under [tool.uv], or the UV_EXCLUDE_NEWER environment variable is set, Update-time leaves that in place instead of overriding it.

Point of contact

Point of contact for this repository is Frank Niessink.

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

update_time-0.0.14.tar.gz (42.9 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

update_time-0.0.14-py3-none-any.whl (58.8 kB view details)

Uploaded Python 3

File details

Details for the file update_time-0.0.14.tar.gz.

File metadata

  • Download URL: update_time-0.0.14.tar.gz
  • Upload date:
  • Size: 42.9 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: uv/0.11.26 {"installer":{"name":"uv","version":"0.11.26","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"macOS","version":null,"id":null,"libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":null}

File hashes

Hashes for update_time-0.0.14.tar.gz
Algorithm Hash digest
SHA256 f8a40297f846d91f36427f77b8a9c47c0991c2a51c7c3f4f308abcaeec63b6e0
MD5 6da0b574212e6910b540b9f7a4ed5d07
BLAKE2b-256 812b5629f94edf381217130584bb6f21c0dc31d5c90b577763fb6621410c8b55

See more details on using hashes here.

File details

Details for the file update_time-0.0.14-py3-none-any.whl.

File metadata

  • Download URL: update_time-0.0.14-py3-none-any.whl
  • Upload date:
  • Size: 58.8 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: uv/0.11.26 {"installer":{"name":"uv","version":"0.11.26","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"macOS","version":null,"id":null,"libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":null}

File hashes

Hashes for update_time-0.0.14-py3-none-any.whl
Algorithm Hash digest
SHA256 6207c76082df9e60affd12b7770ab2db49550dde5f0d0b7cac40d6897efe6ce0
MD5 c6fda1a42445942435394def7eb2d8ba
BLAKE2b-256 eed449cfd6faec5adbf2c260ad7258085aa358f103f45587441cf90a426012b4

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page