Skip to content

release: 0.2.0, so that pip --upgrade actually delivers it - #4

Merged
adiazpar merged 1 commit into
mainfrom
release/0.2.0
Aug 8, 2026
Merged

release: 0.2.0, so that pip --upgrade actually delivers it#4
adiazpar merged 1 commit into
mainfrom
release/0.2.0

Conversation

@adiazpar

@adiazpar adiazpar commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

A user reported still having the old version after installing from the git URL. Reproduced
from a clean environment against the pre-refactor commit:

Command Result
pip install git+… no change
pip install --upgrade git+… no change
pip install --force-reinstall git+… works

Why

Not a pip bug. Installing from a git URL does not use tags — this repo has none. pip
clones the default branch, reads version out of pyproject.toml, and compares that single
string against what is installed. Every change since the first release went out under
0.1.0, so pip compared 0.1.0 to 0.1.0 and concluded there was nothing to do.

It had already cloned the new code and recorded the new commit id in direct_url.json. It
threw the clone away.

So the entire refactor — baseline-free authoring, the shipped palette, the flute-pitch fix —
was unreachable by the upgrade command the README tells people to run.

0.2.0 is also the honest number: --out is gone, author_sound_timeline's arguments
swapped, and the pytest marker was renamed.

What was never wrong

Replacement itself. Verified that pip uninstalls the old distribution first, so none of the
six modules from the old flat layout (palette.py, midi.py, gm.py, voices.py,
events.py, timeline.py) survive alongside the new subpackages. One dist-info, no
duplicates.

tests/test_packaging.py

New, and it had no counterpart. The version is declared twice — pyproject.toml and
__init__.py — and nothing connected them; a release where those disagree ships a package
that reports one number and upgrades on another.

It also pins the two packaging fields whose failure mode is silent and total:

  • the explicit packages list — a forgotten subpackage installs fine and fails on import
  • package-data — a missing entry drops the sound palette out of the wheel, and every
    compile raises on a machine that installed rather than cloned

README

Documents the upgrade command, why it did nothing, and the one-time --force-reinstall that
unsticks it — plus @ref for pinning a specific version.

134 passed, 4 skipped.

A user reported still having the old version after installing from the git
URL. Reproduced from a clean environment against the pre-refactor commit:

  pip install git+...              -> no change
  pip install --upgrade git+...    -> no change
  pip install --force-reinstall    -> works

Not a pip bug. Installing from a git URL does not use tags -- this repo has
none. pip clones the default branch, reads `version` out of pyproject.toml,
and compares that single string against what is installed. Every change
since the first release went out under 0.1.0, so pip compared 0.1.0 to
0.1.0 and concluded there was nothing to do. It had already cloned the new
code and recorded the new commit id in direct_url.json; it threw the clone
away.

So the entire refactor -- baseline-free authoring, the shipped palette, the
flute-pitch fix -- was unreachable by the upgrade command the README
tells people to run. The version is the only thing that decides that, and
it never moved. 0.2.0 is also the honest number: --out is gone,
author_sound_timeline's arguments swapped, and the pytest marker was
renamed.

Replacement itself was never the problem -- verified that pip uninstalls
the old distribution before installing, so none of the six modules from the
old flat layout survive alongside the new subpackages.

Adds tests/test_packaging.py, which had no counterpart. The version is
declared twice, in pyproject.toml and __init__.py, and nothing connected
them; a release where those disagree ships a package that reports one
number and upgrades on another. It also pins the two packaging fields whose
failure mode is silent and total: the explicit `packages` list, where a
forgotten subpackage installs fine and fails on import, and `package-data`,
where a missing entry drops the sound palette out of the wheel and makes
every compile raise on a machine that installed rather than cloned.

README documents the upgrade command, why it did nothing, and the one-time
force-reinstall that unsticks it.
@adiazpar
adiazpar merged commit e457e0b into main Aug 8, 2026
3 checks passed
@adiazpar
adiazpar deleted the release/0.2.0 branch August 8, 2026 15:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant