openkal-musl 0.3.1: name the implementation by version, because a published package must - #3
Merged
Merged
Conversation
…lished package must The manifest named the implementation of openkal for each system by a path. That is right in a working tree that has the three repositories side by side, and it is wrong in a package: a path names a directory that exists where the manifest was written and nowhere else, so a consumer resolving this package from the index was handed a dependency pointing at nothing --- reported as "path dependency 'openkal-linux' has no mcpp.toml", inside the registry's own store. It is named by version now, with the feature travelling beside it, because a program above this library carries no other runtime and that is what the feature states. The defect was found by resolving the package the way a stranger would, from a store with no local copy of it. That check exists for exactly this: a working tree masks every mistake in a manifest's dependencies, because the tree is what the manifest was written against. tools/working-trees.sh rewrites the implementation reference as well as the specification's, so that continuous integration goes on asserting what it is for --- that these sources and that implementation as written today work together --- while the published manifest says what a published manifest must.
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
1 participant
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.
The manifest named the implementation of openkal for each system by a path.
That is right in a working tree that has the three repositories side by side, and
it is wrong in a package: a path names a directory that exists where the manifest
was written and nowhere else.
A consumer resolving this package from the index was therefore handed a
dependency pointing at nothing:
The feature travels beside the version, because a program above this library
carries no other runtime and that is what the feature states.
How it was found
By resolving the package the way a stranger would — from a store with every local
copy of it deleted. That check exists for exactly this: a working tree masks every
mistake in a manifest's dependencies, because the tree is what the manifest was
written against.
tools/working-trees.shnow rewrites the implementation reference as well as thespecification's, so continuous integration goes on asserting what it is for —
that these sources and that implementation as written today work together —
while the published manifest says what a published manifest must.