Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[#355] Add Custom Version Matcher #508
Leaving this here for reference/potential future additions:
I should be able to test this PR more later this week.
I also wonder how much it changes things that I'm only getting "VERSION" out of rpm and ignoring epoch and others:
Just got back from my travels, decided to give this a quick go on my laptop to see how it works. The matcher should be renamed to clarify that it's a
I see the wheezy error you mention:
package: bash: installed: true versions: # This is what the command returns #- 4.2+dfsg-0.1+deb7u3 version-gt: "4.4.0"
Running this on all the wheezy packages in the docker test image gets the following result:
Can you clarify what you mean by this? That seems concerning if it's not parsing them correctly is it doing the correct thing when diffing non-semver strings?
I have 2 examples from my unit tests:
"4.3.42-r".GreatherThan("4.0.0") // returns true "4.4.019-1".GreatherThan("4.0.0") // returns true
go-version.Range("4.3.42-r > 4.0.0") // returns false semver.Range("4.4.019-1 > 4.0.0") // errors out since no version segment can start with "0"
With all of this in mind, I propose we follow your plan of naming the Matcher
I will wait for your feedback on the plan before making changes.
This is a great start, really hoping other package managers get solved soon.
The semver matcher might not provide immediate value, but will be valuable in the near future once other work is done.
Preview of some upcoming work that will pair-up greatly with this in my opinion:
Do you think this feature will be released soon? Interesting feature…
On Thu, Dec 5, 2019, 5:19 PM Ahmed Elsabbahy ***@***.***> wrote: semver-constraint + semver package sounds good to me. This is a great start, really hoping other package managers get solved soon. The semver matcher might not provide immediate value, but will be valuable in the near future once other work is done. Preview of some upcoming work that will pair-up greatly with this in my opinion: - Migrating http/command/file to use gomega matchers. They were an older implementation and it's a little tricky to convert to gomega matchers because they're io.Reader. I don't want to switch them to arrays, since that could drastically increase the memory usage of goss (ex. someone doing validation on a 1GB log file). Basically gotta write a custom implementation of ContainElement <https://onsi.github.io/gomega/#containelementelement-interface> that uses readers. - jmespath <https://github.com/jmespath/go-jmespath> gomega matcher - Whenever a package type is introduced that strictly adheres to semver (not sure if there are many to be honest) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#508?email_source=notifications&email_token=AITSLFX5K37VEL6OE7LXGBTQXGD7FA5CNFSM4JTOOXK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGCPOMQ#issuecomment-562362162>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AITSLFS2AEWHNND5DRK7U6TQXGD7FANCNFSM4JTOOXKQ> .
Minor changes requested, aside from that this looks awesome and is good to go on my end. Let me know if you're all done with it.
Fun side note, doing a matching only test with this runs so fast the duration zero's it out =)
Tested it locally, it looks great. I'm going to merge this, just one question:
matching: semver: content: - 1.9.9 - 6.13.2 matches: semver-constraint: ">1.0.0 <2.0.0 !=1.5.0"
Is there a way to check if only one element passes the constraint? If not, do you see the current implementation as easily changed to support that in a future PR? I would prefer composable gomega language if possible, since it allows it to be re-usable.
Real world use-case: package managers sometimes have multiple versions on a system (e.g. kernel) there might be a need to make sure that there's at least one package version installed that matches the constraint.
Just wanna hear your thoughts on this as it's something I would like to support around the same time deb/rpm support comes in.
My quick view/guess on this is, it might be possible with a simple gomega matcher that wraps semver-constraint. Something like:
Since it seems you wrote the constraint in a way that works for a single string, which is awesome!