-
Notifications
You must be signed in to change notification settings - Fork 4
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
Versions cannot contain spaces #23
Comments
Spaces! My lord what has the world come to. Okay I've looked at the associated issues on your repository, as well as the 7zip releases page. It seems that the title of the releases uses spaces, but the git tag has proper Accepting spaces in version numbers (even in the |
My tool allows users to add or update applications to winget (Microsoft's package manager for Windows). Each application has some metadata files and in those there is a package version (Example). The package versions at winget-pkgs/manifests/m/mcmilk/7zip-zstd are already pre-existing versions for In Microsoft's schema for this, they actually just have a regex for validating the version: "PackageVersion": {
"type": "string",
"pattern": "^[^\\\\/:\\*\\?\"<>\\|\\x01-\\x1f]+$",
"maxLength": 128,
"description": "The package version"
}, In short, the regex just says it can't contain some specific control characters and beyond that, what constitutes a version can be anything, and winget will attempt to order it regardless. |
The following test passes: #[test]
fn mess_7zip() {
cmp_messes("22.01-ZS-v1.5.5-R2", "22.01-ZS-v1.5.6-R2");
}
fn cmp_messes(a: &str, b: &str) {
let x = Mess::new(a).unwrap();
let y = Mess::new(b).unwrap();
assert!(x < y, "{} < {}", x, y);
} But so does: cmp_messes("22.01-ZS-v1.5.5-R2", "24.02-ZS-v1.6.0"); Since even with the I think it's best to remain firm that whitespaces shouldn't be accepted in version numbers, even mostly lawless ones as we see here. If they are present, I think it's reasonable to do some preprocessing in downstream code before parsing. |
Preprocessing is unfeasible in my case as I take in a version straight from a clap parameter and serialize it into Yaml. Even if I were to do some changes to the version, I need it to be the exact same as what the user inputted to what value is serialized in the end. If it were more feasible, it would also add a lot of unnecessary complexity just to workaround this issue of mess not working with spaces. I'd really appreciate it if you could add support for spaces - it would arguably make this library more robust with the intention of being able to parse any messy version and still be able to compare it. |
Let's discuss this. Were I to support spaces in
|
I do think it's unlikely that anyone is matching over Sep. If anyone were, they could either use
Again, from checking the reverse dependencies, no one appears to be using this. The usages I saw were mostly Versioning, SemVer, and a couple usages of Chunk. Granted these are only ones that are on crates.io, but although this may technically be breaking, I can't see it having an impact or even affecting any code bases. |
I've since had another user report an instance of an app having a version with spaces in it: |
Thanks for the follow-up. I do intend to solve this as soon as I'm able. |
Hello, I'm running into this as well. I'm using The output looks a bit like this:
Here, I can work around this by removing the suffix, but I thought I'd make a comment here. It might be nice to have a "permissive parser" which ignores or otherwise segments out extra information like this. |
Hi there. In this case I'd recommend a preemptive call to https://doc.rust-lang.org/std/primitive.str.html#method.split_once to remove anything past the first whitespace, and then call |
I had a user report of an error with parsing a version:
Both of these are due to the same issue of being unable to parse a version with spaces in. The version in question looks like
22.01 ZS v1.5.5 R2
(See winget-pkgs/manifests/m/mcmilk/7zip-zstd). It works correctly if the spaces are replaced with a delimiter, such as-
.The text was updated successfully, but these errors were encountered: