feat(packaging): publish the CLI as pz, not Pz.Cli - #4
Merged
Conversation
The install line is the first thing a stranger runs, and an id they have to
be told ("it's Pz.Cli, with a dot") is friction on the one command that has
to work before any other. `<PackageId>pz</PackageId>` makes
`dotnet tool install -g pz` the real line; the project, assembly, and
namespace stay Pz.Cli, so this is the single place the two names diverge.
scripts/lib/packable-ids.sh derived the expected package set from project
names, which is now one name short of the truth -- it reads each project's
<PackageId> and falls back to the project name, so the derivation keeps
working for any future override too.
Two consequences no code can enforce, so both are written down where the
person doing them will look:
- The nuget.org trusted publishing policy globs ids as "Pz.*", which a bare
"pz" does not match. Without a policy naming it, release.yml's push fails
authentication for this package alone, after the other three have already
published against a tag that cannot be reused. CONTRIBUTING.md's policy
setup and release.yml's prerequisites block both say so now.
- Pz.Cli published 0.1.0 through 0.2.0 and keeps resolving forever; NuGet has
no redirect. It gets deprecated on nuget.org pointing at `pz`, stays listed
so existing lock files restore, and must not be published under both ids --
two packages claiming the same `pz` shim make the second install fail. The
README tells an existing user to uninstall first, and the offline bundle's
install.ps1 removes a legacy tool-path install before installing `pz`.
Verified with scripts/verify-tool-install.sh: pack -> tool install by the new
id from a local-feed-only config -> offline `pz init` -> offline `pz run
--all`, 12/12 nodes.
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.
Makes the install line
dotnet tool install -g pz.<PackageId>pz</PackageId>onPz.Cli.csprojis the whole functional change; the project, assembly, and namespace keep their names, so this is the one place a published id differs from a project name.scripts/lib/packable-ids.shderived the expected package set from project names, which is now one name short of the truth. It reads each project's<PackageId>and falls back to the project name, so the derivation survives this override and any future one.pzis unclaimed on nuget.org (no package, no versions), so the id is available.Two manual steps this PR cannot do
Both are written into
CONTRIBUTING.md's release section andrelease.yml's prerequisites block, where whoever cuts the release will look:pz. The existing policy globsPz.*, which does not match a barepz. Without widening it (or adding a second policy), the release push fails authentication for this package alone — after the other three have published against a tag that can't be reused.Pz.Clion nuget.org ("Other", alternate packagepz) and leave its versions listed so existing lock files still restore. Don't publish under both ids: two packages claiming the samepzshim make the second global install fail.Existing users
NuGet has no redirect, so
dotnet tool update -g Pz.Clistays pinned at0.2.0, and installingpzover a globalPz.Clifails on the shim collision. The README now says to uninstall first, and the offline bundle'sinstall.ps1removes a legacy tool-path install before installingpz.Verification
dotnet build Pz.slnx -c Release— 0 warnings, 0 errorsdotnet test Pz.slnx -c Release --no-build(PZ_TESTS_OFFLINE=1) — 0 failedscripts/verify-tool-install.sh— pack →dotnet tool install pzfrom a local-feed-only config → offlinepz init→ offlinepz run --all, 12/12 nodes. PASS.Follow-up in
pz-siteFour install lines need the new id; the other
Pz.Climentions there are project paths and stay correct.src/content/docs/quickstart.md:19src/content/docs/index.mdx:190src/content/docs/articles/10-meet-pz.md:21src/content/docs/how-to/run-scheduled-on-windows.md:29