Prefer standard shards semantics in native setup#21
Open
crimson-knight wants to merge 1 commit intomainfrom
Open
Prefer standard shards semantics in native setup#21crimson-knight wants to merge 1 commit intomainfrom
crimson-knight wants to merge 1 commit intomainfrom
Conversation
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.
Summary
Document Amber CLI's compatibility target for upstream Shards plus the additive fork currently distributed as
shards-alpha, and make the native scaffold prefershards installbefore falling back to the fork's current binary name.Why
If the fork is truly compatible, Amber should keep teaching the standard
shardsworkflow first. The CLI only needs a light adjustment here, but it helps keep the public story clean while the fork grows stronger compatibility guardrails.Decision Record
The generated app should center the standard Shards command path and let PATH or a fallback handle compatible forks. That keeps onboarding stable for new Amber users while still tolerating the current
shards-alphadistribution name.Verification
git diff --checkAMBER_CLI_PATH=../amber_cli CRYSTAL_OPTS='--link-flags=-fuse-ld=ld' ../shards/scripts/validate_amber_cli_compatibility.shRelease Impact
This keeps Amber's generated native setup aligned with the compatibility contract now enforced in the Shards fork.
Risks And Rollback
The main risk is very small: a machine with only
shards-alphainstalled still depends on the fallback branch of the setup command. If that becomes noisy, this is easy to revert without affecting the broader compatibility work.