Skip to content

[pull] master from django-tenants:master - #89

Merged
pull[bot] merged 7 commits into
Dresdn:masterfrom
django-tenants:master
Aug 6, 2026
Merged

pull[bot] merged 7 commits into
Dresdn:masterfrom
django-tenants:master

Conversation

@pull

@pull pull Bot commented Aug 6, 2026 •

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

tomturner and others added 7 commits August 5, 2026 17:03
The command only overrode run_from_argv, so anything reaching it through
call_command() fell through to BaseCommand.handle and raised
NotImplementedError. It is documented but had no test coverage.

- Add handle(), which runs the wrapped command on every tenant. The
  command line still goes through run_from_argv() so that options
  belonging to the wrapped command need not be declared here.
- --no-public is now removed from argv wherever it appears. It was
  assumed to sit immediately after the command name, so putting it after
  the wrapped command's name reported "Unknown command: '--no-public'".
- Invoking with no command name silently did nothing; it and --help now
  hand back to Django's parser, which reports the missing argument and
  prints usage.
- Drop a leftover debug print() of the parsed argv, and the argparse
  round trip that only ever echoed its input back.

Document calling it from Python, including that the wrapped command's own
options are command line only.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The new tests only drove handle(), so run_from_argv() -- which is what
manage.py actually calls -- was untested, leaving 17 lines of the patch
uncovered. These drive the command the way manage.py does: passthrough of
the wrapped command's own options, --no-public appearing after the command
name, an already-loaded BaseCommand instance from get_commands(), and the
exit codes for an unknown command, a missing command name and --help.

Takes all_tenants_command.py from 48% to 100%.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…-command

# Conflicts:
#	django_tenants/tests/test_commands.py
Django 6.1 was released on 5 August 2026 and requires PostgreSQL 15 or
later. The Postgres compatibility job installs Django unpinned, on purpose
-- the point of that job is the server version, not the Django version --
so as soon as 6.1 reached PyPI the PostgreSQL 14 entry started failing at
connection setup with

    NotSupportedError: PostgreSQL 15 or later is required (found 14.23)

before any project code ran. django-tenants still supports Django 5.2,
which supports PostgreSQL 14, so the server is worth testing rather than
dropping. Install the newest series that still accepts it instead.

Also stop the matrix cancelling itself: with fail-fast, PostgreSQL 14
going out of support took 15, 16 and 17 down with it and left nothing to
read. Verified locally: 14 with Django 6.0.8 and 17 with Django 6.1 both
run run_tests.sh clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…o-6.1

Test PostgreSQL 14 against the newest Django that supports it
Give all_tenants_command a handle() so call_command works (#627)
@pull pull Bot locked and limited conversation to collaborators Aug 6, 2026
@pull pull Bot added the ⤵️ pull label Aug 6, 2026
@pull
pull Bot merged commit 52b74e0 into Dresdn:master Aug 6, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant