[packaging] assimulo optional extra cannot be installed by pip (not on PyPI)

[parkyr]

Problem

pyproject.toml's [project.optional-dependencies].assimulo pins
assimulo==3.4.3, and requirements-assimulo.txt mirrors it — but that version
(indeed every version above 3.0) is absent from PyPI. Any pip/uv install of
the extra therefore fails to resolve. Assimulo 3.4.3 exists only on conda-forge
and as source at modelon-community/Assimulo.

This is a packaging-correctness / documentation defect, not a runtime or CI bug.

Evidence

PyPI's assimulo project tops out at 3.0, so both the bare pin and the extra
fail to resolve:

$ uv pip install "assimulo==3.4.3"
  × No solution found when resolving dependencies:
  ╰─▶ Because there is no version of assimulo==3.4.3 and you require
      assimulo==3.4.3, we can conclude that your requirements are
      unsatisfiable.

$ uv pip install ".[assimulo]"
  × No solution found when resolving dependencies:
  ╰─▶ Because there is no version of assimulo==3.4.3 and
      pharmapy[assimulo]==0.0.1 depends on assimulo==3.4.3, we can conclude
      that pharmapy[assimulo]==0.0.1 cannot be used.
      ...your requirements are unsatisfiable.

Plain pip install "PharmaPy[assimulo]" fails equivalently ("Could not find a
version that satisfies the requirement assimulo==3.4.3").

Additional context:

• DEPENDENCIES.md already notes that assimulo "is difficult to build on common
  pip-only environments," and declares pyproject.toml the source of truth with
  requirements.txt / requirements-assimulo.txt as convenience mirrors — but
  the mirror advertises a pip install that cannot succeed.
• CI never exercises the pip path. In .github/workflows/ci.yml, core-tests
  installs .[test] (no assimulo) and integration-assimulo sources assimulo
  from conda via environment.yml, then runs pip install -e . --no-deps. So
  the broken extra is invisible to CI and only bites a human who tries the pip
  path directly.

Impact

Latent footgun for contributors/users who follow the extra's implied promise:
they hit an opaque "no matching distribution" resolver error with no pointer to
the working conda (environment.yml) or source-build path. Zero CI impact —
no job depends on the broken path. Low priority, but the metadata is misleading.

Note: no modern assimulo is published on PyPI at all, so there is no version bump
that makes the pip path work — assimulo is fundamentally conda/source-only.

Recommended fix (proposed — "remove the false pip promise")

To be done in a small follow-up PR (not part of this issue):

• Remove assimulo==3.4.3 from the pyproject.toml assimulo extra. Keep the
  pip-installable cython>=0.29,<3 build dependency, or drop the extra entirely
  if cython alone doesn't justify it (maintainer's call).
• Remove the assimulo==3.4.3 line from requirements-assimulo.txt (leaving
  cython + -r requirements.txt), or delete the file if it no longer earns its
  place.
• Rewrite the relevant DEPENDENCIES.md paragraph to state plainly that assimulo
  is not pip-installable and must come from conda-forge (environment.yml) or
  a source build; keep 3.4.3 documented as the supported version in prose rather
  than as an unresolvable pin.
• Add a one-line note in TESTING.md that pip install "PharmaPy[assimulo]" does
  not work, pointing to the conda flow already documented there.

After this, pip install "PharmaPy[assimulo]" no longer errors and the metadata
no longer promises something pip cannot deliver. environment.yml (the real,
working assimulo path) stays unchanged.

Alternatives considered (short-term)

Option	Pros	Cons
A. Remove the false pip promise (recommended)	Honest metadata; pip install .[assimulo] stops erroring; small diff	Loses machine-readable 3.4.3 pin (kept in prose); needs DEPENDENCIES.md rewrite
B. Keep the pin, document as conda-only	Lowest churn; preserves the version pin	pip install .[assimulo] still errors — footgun documented, not removed
C. Point the extra at a source URL (assimulo @ git+https://…@Assimulo-3.4.3)	pip attempts the correct source	Still fails without SUNDIALS + gfortran + numpy<2; looks installable but usually isn't

Longer-term options (for discussion, not this issue)

Option	Pros	Cons
1. Commit a reproducible source-build script (SUNDIALS 6.6.2 with SUNDIALS_INDEX_SIZE=32 + LAPACK, then assimulo 3.4.3 with gfortran -fallow-argument-mismatch and numpy<2)	Gives pip-only users a real, supported (if slow) path; captures the build recipe as a repo asset + living docs	Linux-specific as written; ~5–10 min build; another script to maintain
2. Build & host assimulo wheels (manylinux/macos/windows) in CI; extra points at them via --find-links/URL	Makes pip install fast and genuinely work	Real maintenance: platform matrix, rebuilds per assimulo/SUNDIALS bump, hosting
3. Officially conda-only; drop pip-facing assimulo scaffolding	Simplest, least maintenance; matches current reality	Abandons pip-only users; contradicts the "broader solver stack" aspiration in DEPENDENCIES.md
4. Track/petition an upstream PyPI release	Near-zero effort if it happens	Out of the project's control; unlikely soon

Suggested trajectory: short-term A now, long-term 1 as the highest-value
next step (a real path without the hosting burden of option 2).

---

Related: #8 (packaging & project-metadata modernization).

_{Discovered while setting up a local pip/uv virtual environment for PharmaPy testing.}