fix: pypi and pixi dev environment dependency version drift

[allison-truhlar]

This PR updates the constraints on the pixi dev environment dependencies, listed under [tool.pixi.dependencies], to match the constraints set for the PyPi build, found under dependencies in pyproject.toml. This was motivated by PR #375 and the need to update the version of Starlette in the dev env to match the version in production. This PR goes beyond this by modifying all the dependency constraints to match, in an attempt to prevent other dependency version drift between dev and production from occurring.

@mkitti @neomorphic @krokicki

[mkitti]

To be honest, I think it's slightly more conservative to have lower and upper bounds on everything unless we can clearly demonstrate that the dependencies do not use semantic versioning.

That is we should not casually update a package that does changes its major version. I would not want to just update to Pandas version 3 from version 2 without intentionally examining the situation. According to Pandas, this should indicate an API breaking change: https://pandas.pydata.org/docs/development/policies.html .

Is it possible to do this for both PyPI and conda-forge dependencies consistently?

[mkitti]

Dependency versioning-scheme analysis & proposed synchronized bounds

I verified the versioning scheme and latest release of each runtime dependency to align the PyPI ([project].dependencies) and conda-forge/pixi ([tool.pixi.dependencies]) bounds. The bounds follow SemVer principles — cap = floor's major + 1 for ≥1.0 packages, and cap = floor's minor + 1 for 0.x packages (where 0.x treats minor as the breaking boundary) — except for the two packages flagged below that use a non-SemVer scheme.

Package	Scheme	Floor	Latest	Cap rule	Proposed bound
alembic	SemVer (1.x)	1.17.0	1.18.4	major+1	>=1.17.0,<2
atlassian-python-api	SemVer (0–4)	4.0.7	4.0.7	major+1	>=4.0.7,<5
authlib	SemVer (1.x)	1.6.5	1.7.2	major+1	>=1.6.5,<2
cachetools	SemVer (→7)	6.2.1	7.1.4	major+1	>=6.2.1,<7
click	SemVer (→8)	8.0	8.4.1	major+1	>=8.0,<9 ← new cap
fastapi	0.x (minor=breaking)	0.119.1	0.136.3	minor+1	>=0.119.1,<0.120
httpx2	SemVer (2.x)	2.2.0	2.3.0	major+1	>=2.2.0,<3
itsdangerous	SemVer (2.x)	2.2.0	2.2.0	major+1	>=2.2.0,<3
loguru	0.x (minor=breaking)	0.7.3	0.7.3	minor+1	>=0.7.3,<0.8
pandas	SemVer (2.x)	2.3.3	3.0.3	major+1	>=2.3.3,<3
psycopg2-binary	SemVer (2.x)	2.9.10	2.9.12	major+1	>=2.9.10,<3
pydantic	SemVer (2.x)	2.10.6	2.13.4	major+1	>=2.10.6,<3
pydantic-settings	SemVer (2.x)	2.11.0	2.14.1	major+1	>=2.11.0,<3
python-jose	SemVer (3.x)	3.5.0	3.5.0	major+1	>=3.5.0,<4
cryptography	rolling-major (41→48)	41.0.0	48.0.0	none	>=41.0.0 (uncapped)
sqlalchemy	SemVer (2.x)	2.0.44	2.0.50	major+1	>=2.0.44,<3
packaging	CalVer (24, 25, 26)	24.0	26.2	none	>=24.0 (uncapped)
uvicorn	0.x (minor=breaking)	0.38.0	0.48.0	minor+1	>=0.38.0,<0.39
x2s3	SemVer (1.x), 1st-party	1.2.0	1.2.0	major+1	>=1.2.0,<2 ← new cap
py-cluster-api	0.x, 1st-party	0.6.0	0.6.0	minor+1	>=0.6.0,<0.7 ← new cap

Scheme exceptions (do not SemVer-cap)

• cryptography bumps its major every feature release (41 → 42 → … → 48); a <next-major> cap would break on the very next normal release. Leave >=41.0.0 uncapped.
• packaging is CalVer (24.0, 25.0, 26.2 — year-based), not SemVer. Leave >=24.0 uncapped.

conda-forge availability for packages currently missing from the pixi block

• psycopg2-binary — available on conda-forge (2.9.10). Add to [tool.pixi.dependencies] as >=2.9.10,<3.
• x2s3 and py-cluster-api — 404 on conda-forge (PyPI-only, first-party). They cannot be conda dependencies; they reach the environment via the editable pypi-dependencies install, so they stay out of the pixi block.

Net result

Both blocks would list the same runtime packages with identical bounds, except:

• python / pip / nodejs — pixi-only build tooling.
• x2s3 / py-cluster-api — PyPI-only (not on conda-forge).

Open question: x2s3 and py-cluster-api are first-party — since we control their release cadence, we may prefer to leave them uncapped rather than apply the proposed <2 / <0.7 caps.

[allison-truhlar]

Closed in favor of #378