release: 0.2.0, so that pip --upgrade actually delivers it - #4
Merged
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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+…pip install --upgrade git+…pip install --force-reinstall git+…Why
Not a pip bug. Installing from a git URL does not use tags — this repo has none. pip
clones the default branch, reads
versionout ofpyproject.toml, and compares that singlestring against what is installed. Every change since the first release went out under
0.1.0, so pip compared0.1.0to0.1.0and concluded there was nothing to do.It had already cloned the new code and recorded the new commit id in
direct_url.json. Itthrew 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.0is also the honest number:--outis gone,author_sound_timeline's argumentsswapped, 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, noduplicates.
tests/test_packaging.py
New, and it had no counterpart. The version is declared twice —
pyproject.tomland__init__.py— and nothing connected them; a release where those disagree ships a packagethat reports one number and upgrades on another.
It also pins the two packaging fields whose failure mode is silent and total:
packageslist — a forgotten subpackage installs fine and fails on importpackage-data— a missing entry drops the sound palette out of the wheel, and everycompile raises on a machine that installed rather than cloned
README
Documents the upgrade command, why it did nothing, and the one-time
--force-reinstallthatunsticks it — plus
@reffor pinning a specific version.134 passed, 4 skipped.