Fix #282, #283, #284 — footer link override, settings env namespacing, package-update pin style

[antosubash]

Fixes the three open issues that had no PR. Each is a separate commit; a fourth generalises #283's root cause, which turned out to affect five more settings classes, and a fifth fixes findings from reviewing the branch.

Closes #282, closes #283, closes #284.

#284 — smpy package-update rewrote pin style, not just versions

package-update rewrote every constraint to name>=, so bumping versions silently changed a project's pinning policy. A host pinned at ==0.0.32 came back as >=0.0.32 while the module wheels it depends on still pin exactly, leaving the effective version decided by whichever wheel pins hardest.

The bump now changes the version and nothing else:

Constraint	Latest	Result
==0.0.32	0.0.33	==0.0.33
>=0.0.32	0.0.33	>=0.0.33
~=1.4.2	1.4.9	~=1.4.9 — same compatible band
~=1.4	2.0.0	unchanged, reported — ~=1.4 means >=1.4, ==1.*
==1.0.*	1.0.5	unchanged — the band already allows it
==1.0.*	1.1.0	unchanged, reported
>=1.0,!=1.0.*	1.0.5	unchanged, reported
>0.0.1	0.0.33	unchanged — already satisfied, and >0.0.33 would exclude the release being installed
>=0.1,<1.0	2.0.0	unchanged, reported as 2.0.0 excluded by <1.0
>=0.1,<3.0	2.0.0	>=2.0.0,<3.0
(no constraint)	0.0.33	>=0.0.33 — no pin style to preserve

Wildcards and ~= are the subtle half. version_key maps * to 0, so comparing !=1.0.* numerically reads it as !=1.0.0 and it never fires — which produced >=1.0.5,!=1.0.*, a specifier nothing can satisfy, right before the tool tells you to run uv sync. Wildcards now match on a release-segment prefix and never reach the numeric comparison, and ~= moves only within the band it implies.

--loosen restores the previous blanket >= rewrite.

Two incidental fixes fall out of parsing requirements properly rather than splitting on the first operator: extras (pkg[redis]) and environment markers (; python_version >= '3.12') now survive, where before they were dropped.

Requirement parsing moves to requirements.py and the PyPI lookup to pypi.py, keeping every file under the 300-line cap.

#283 — BackgroundTasksSettings read unprefixed env vars

SettingsConfigDict(extra="ignore") with no env_prefix doesn't disable env reads — it un-namespaces them, so pydantic resolved each field from its bare name. The documented SM_BG_TASKS_* names did nothing while broker_url, result_backend, retention_days and friends were live reads.

Setting env_prefix=ENV_PREFIX gives the class one rule and aligns it with the docstring, settings.env_vars, the docker-compose recipe, tasks.py and _assert_broker_isolated — all of which already assumed the prefix. The one-off default_factory reads and the env_bool call on task_always_eager become redundant and go — the env source answers those names now. (The broker and result-backend factories come back in the merge below, for SM_REDIS_URL rather than for their own names.)

The localhost validator also names the mechanism it expects. It was most people's first encounter with this and said only "set these to the Redis service host", so the natural guess was the prefixed name that had no effect.

Breaking: deployments relying on the accidental bare names must rename them to SM_BG_TASKS_*.

The same bug in five more classes

The cause wasn't specific to background_tasks. Verified on main, with these variables set in the environment:

SiteLockSettings()     -> enabled=True  password='hunter2'
UsersSettings()        -> smtp_host='evil.example.com' base_url='http://evil.example.com'
FileStorageSettings()  -> backend='s3'  s3_bucket='attacker-bucket'

enabled, password, backend, base_url and client_secret are common enough in a container that an unrelated component setting one silently reconfigures the app — and site_lock's pair is the site gate, while users' base_url is the origin of password-reset links.

DbBackedSettings (new, in simple_module_core.settings_base) keeps only the init source, so values come from the constructor — which is how DB hydration already sets them — and nothing else. site_lock, users, file_storage, settings and branding now subclass it. This is what _module_settings.py already told the admin UI was true, and what the 2026-04-21 DB-backed-settings plan intended by dropping env_prefix.

background_tasks deliberately keeps BaseSettings + an explicit prefix: its broker URL must be readable before any DB row exists.

HostSettings was in that list until #290 landed on main. #290 makes it deliberately env-readable — its docstring states "Precedence is env → DB → the defaults declared here" — and _preapp_config.merge_host_settings reads it before create_app builds anything, so dropping the env source would break the first-run setup wizard. Its env_prefix="SM_" already closes the bare-name hole this issue reported, which is the part that mattered; the merge takes main's version, and the Settings shim goes back to main's too, since the source override it needed only existed to work around HostSettings having no environment.

background_tasks also picks up #290's SM_REDIS_URL, with one interaction worth naming: with env_prefix set, pydantic's env source answers SM_BG_TASKS_BROKER_URL / SM_BG_TASKS_RESULT_BACKEND before any default factory runs, so #290's deprecation warning — which lived inside that factory — would have gone silent. It moves to a validator that fires when the legacy variable is the value's actual source, and #290's own warning tests pass unchanged.

#282 — footer links hardcoded to the framework repo

BRAND_FOOTER_LINKS was a module-level constant and BrandingFooter mapped over it directly, so every app advertised antosubash/simple_module_python on every page. The configurable footer from #222 was removed by #273/#275, taking the only override with it.

footer_links joins the other branding values: DB-backed, in the branding shared prop as footerLinks, and edited at /admin/branding without a redeploy. BrandingFooter takes an optional links prop and falls back to BRAND_FOOTER_LINKS when it is absent, null or empty — so a deployment that never sets any keeps today's footer, and clearing the list is how you go back to it.

Deliberately just {label, href}, capped at 6. What #273 removed had grown columns, social icons and a tagline; what hosts actually lost was the ability to stop advertising the framework's repository.

href is checked against an allow-list — http://, https://, mailto:, or a site-relative path starting with a single /. The value is rendered straight into an <a href> on every page, signed-in or not, so javascript: and data: would make this screen a stored-XSS sink for anyone holding branding.manage. Scheme-relative //host is rejected, and so are raw backslashes: browsers normalise \ to / in the authority position, so /\evil.example.com reads as a same-site path but navigates off-site. %5C still works for a backslash in a path, since percent-decoding happens after the authority is parsed.

Also fixes change detection in apply_changes_and_reload, which compared changes against the settings attribute. A field typed as a list of models holds model instances while changes carries plain dicts, so an unchanged list never compared equal and was rewritten on every save.

Verification

On the merge of main (88d4c81):

• uv run pytest — 2379 passed, 46 deselected
• make test-js — 139 passed across 23 files
• make lint — clean (the one Biome warning, an unused import in background_tasks/pages/components/ExecutionRow.tsx, is pre-existing on main and untouched here)
• make doctor — 0 diagnostics

New tests: framework/cli/tests/test_cli_package_update_pins.py (pin styles, wildcards, ~= bands, upper bounds, extras/markers, --loosen), framework/core/tests/test_settings_base.py, modules/background_tasks/tests/test_bg_settings_env.py, modules/branding/tests/test_footer_links.py (including the href allow-list), and packages/ui/src/components/BrandingFooter.test.tsx.

Notes for review

main moved four merges ahead while this branch sat, and #290 reworked the same env-vs-DB question #283 touched — see the merge commit 88d4c81 for how each conflict was decided. One non-conflict casualty: SidebarLayout.tsx crossed the 300-line cap once #290's growth met the footerLinks prop, so the prop is hoisted to a local to keep the call on one line.

Two design forks in the issues were resolved as follows, both the option the issue leaned toward:

• smpy package-update rewrites exact pins (==) to lower bounds (>=) with no opt-out #284 preserves the operator by default rather than behind a flag, since the tool's job is versions, not pin policy. This changes today's default behaviour; --loosen is the opt-out.
• branding: footer links are hardcoded to the framework repo with no host override since 0.0.32 #282 takes the issue's option 3 (settings-driven, editable in the admin UI) rather than option 1 (a bare prop), since the reported pain is a deployment that can't change the footer without forking.

https://claude.ai/code/session_012k5QBVkMXJqJLVqtWbZJht

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying simple-module-python with    Cloudflare Pages

Latest commit:	88d4c81
Status:	✅  Deploy successful!
Preview URL:	https://09445789.simple-module-python.pages.dev
Branch Preview URL:	https://claude-github-issues-rnukh8.simple-module-python.pages.dev

View logs