Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wingetcreate update should not be case-sensi-weird #30

Closed
mnpenner opened this issue May 27, 2021 · 2 comments · Fixed by #54
Closed

wingetcreate update should not be case-sensi-weird #30

mnpenner opened this issue May 27, 2021 · 2 comments · Fixed by #54
Labels
Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Resolution-Fix-Committed
Milestone

Comments

@mnpenner
Copy link

Brief description of your issue

I was trying to update node.js to the latest ver of of the 14.x branch, but by running winget show openjs.nodejs --versions I noticed its missing 14.16.1 and 14.17.0.

So I tried submitting it:

PS C:\Users\mnpen> wingetcreate new https://nodejs.org/dist/v14.17.0/node-v14.17.0-x64.msi
Downloading and parsing: https://nodejs.org/dist/v14.17.0/node-v14.17.0-x64.msi...

This tool will walk you through a series of questions to help you create your package manifest.

For information about the restrictions for each field, visit https://github.com/microsoft/winget-cli/blob/master/doc/ManifestSpecv1.0.md

Press ENTER to submit the value for each question including accepting the (default) value.

Please enter values for the following fields:
 [PackageIdentifier] The package unique identifier |e.g. Microsoft.VisualStudio|: OpenJS.Nodejs
 [PackageVersion] The package version |e.g. 1.2.3.4|: 14.17.0
 [DefaultLocale] The package meta-data default locale |e.g. en-US|: en-US
 [Publisher] The publisher name |e.g. Microsoft|: Node.js Foundation
 [PackageName] The package name |e.g. Visual Studio|: Node.js
 [License] The package license |e.g. MIT License|:

OK... it doesn't seem to be recognizing that this is an existing package. Maybe there's a different command for updating the existing package? I cancel out, run wingetcreate --help, ahah, yes, of course there is, it's called update.

PS C:\Users\mnpen> wingetcreate update -i OpenJS.Nodejs -u https://nodejs.org/dist/v14.17.0/node-v14.17.0-x64.msi
A GitHub account or personal access token must be linked in order to continue with this command.
Execution of the command is paused until the GitHub login has been completed.

Initiating GitHub login...

Launching web browser... If default web browser does not launch, please go to: https://github.com/login/device
Please enter the following user verification code when prompted: <bleep>

Resuming command execution...
Retrieving latest manifest for OpenJS.Nodejs
ERROR: repos/microsoft/winget-pkgs/contents/manifests/o/OpenJS/Nodejs was not found.
Please check the spelling and casing of the package identifier

Well that's really weird because when I run winget list it explicitly says I have OpenJS.Nodejs installed:

Node.js                                  OpenJS.Nodejs                                        14.16.1             16.2.0       winget

So I go to github to try and figure out what it's actually listed as. I find https://github.com/microsoft/winget-pkgs/tree/master/manifests/o/OpenJS/NodeJS and try again, changing it to capital JS to match the github URL. And indeed, that seems to have found something:

PS C:\Users\mnpen> wingetcreate update -i OpenJS.NodeJS -u https://nodejs.org/dist/v14.17.0/node-v14.17.0-x64.msi
Using GitHub token from cache...
Retrieving latest manifest for OpenJS.NodeJS
Downloading and parsing: https://nodejs.org/dist/v14.17.0/node-v14.17.0-x64.msi...

Generating a preview of your manifests...
Version manifest preview:
# Created using wingetcreate

PackageIdentifier: OpenJS.NodeJS
PackageVersion: 16.2.0
DefaultLocale: en-US
ManifestVersion: 1.0.0
...

But it thinks its 16.2.0 for some reason and doesn't even prompt to ask otherwise. But maybe that's issue #23 ?

Anyway, I'm calling this sensi-weird because it does appear to be case-sensitive but it doesn't match the case that winget list shows, so that's kinda weird.

Steps to reproduce

Try running wingetcreate update -i using an existing package but "wrong" case.

Expected behavior

Just do a case-insensitive match. If different packages are allowed to have the same name but in different cases, that's going to be a whole 'nother problem.

And also, maybe a separate issue, but make winget list show the actual ID in the ID column.

Actual behavior

Doesn't match

Environment

Windows Manifest Creator v0.1.0.1
@ghost ghost added the Needs-Triage label May 27, 2021
@denelon denelon added Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. and removed Needs-Triage labels May 27, 2021
@denelon
Copy link
Contributor

denelon commented May 27, 2021

@mnpenner I opted for "Feature" to look at making the "PackageIdentifier" lookup case insensitive. I agree we have several challenges with casing. In the winget-pkgs repository, we try to honor case sensitive publisher and package names for the sake of preference and branding. The --exact argument requires case sensitivity in the Windows Package Manager client. I think in this case, we should be able to match on an exact package identifier without requiring case sensitive lookup, but when we generate the manifest we do so respecting the directory structure/casing for the "latest" manifest we encounter.

@mnpenner
Copy link
Author

I would think that anywhere the ID is displayed, it can be displayed in the publisher's preferred case, but I can't think of a scenario where any of the searches should be case-sensitive, even with --exact. I would assume --exact means no partial matches (nothing before or after) and case-sensitive duplicate PackageIdentifiers shouldn't be allowed in the first place (not sure if they are or aren't).

@denelon denelon added this to the v.Next - `winget create` milestone May 28, 2021
@ghost ghost added the In-PR label Jun 3, 2021
@ghost ghost added Resolution-Fix-Committed and removed In-PR labels Jun 4, 2021
@denelon denelon modified the milestones: v.Next-Create, v1.0-Create Oct 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Resolution-Fix-Committed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants