Build spec module #305
Build spec module #305
Conversation
is bulkier than needed, I know. But this was written with intent to refactor version_spec to share some of this
aliased is_member to matches for consistency (Set should either have a callable or other uses of matches should return Fn -> bool aliased BuildNumber type for u32
|
Starting to look good already! Might indeed be a little bit over-engineered but that's fine. :) @YeungOnion If you can make it generic that would be great yeah! |
should probably add more tests
…pturing both motive is that this is already implemented for build spec this couples eq and ord since VersionOperator already couples those together
YeungOnion
force-pushed
the
build_spec_module
branch
from
27f6dfa
to
8bb1cd8
Compare
the deprecated tags were removed as well
YeungOnion
force-pushed
the
build_spec_module
branch
from
8070294
to
a715aeb
Compare
| Version::from_str("1.2.3").unwrap() | ||
| ), | ||
| VersionSpec::Range(RangeOperator::Less, Version::from_str("2.0.0").unwrap()), | ||
| VersionSpec::OrdRange(OrdOperator::Ge, Version::from_str("1.2.3").unwrap()), |
There was a problem hiding this comment.
looks like fmt not working here
|
Think in my overzealousness and irregularity on working on this, I missed this and I'm not sure if I deprecated any feature there. I don't see a diff where I move |
unsure how to direct test build number from match spec
|
Hi @YeungOnion this was added to support the case where a Version like The range While in most cases like an equality of a single version Hope that this gives the needed context. |
|
I think this gives a good chunk of the context. I still don't understand why the operator alone isn't enough, I do see that there's a different Is it not used explicitly as part of the spec? I see that it's not used in the version constraint enum and I may be misunderstand where a user would specify that a spec is for a |
|
Separate meta topic: I think my PR got far too big. Looking for feedback or tips for not doing things like this in the future. As you can see, I've not the practice or discipline of incremental progress yet. |
previously did not handle invalid operator that was not string of OrdOperator symbols
|
I'll start a few new PR's as this one modified more than it needed to at once. I also cut back on some unneeded generality. |
I think this is a little bigger than it needed to be, but I felt like I'd necessarily need to reimplement a slightly smaller version of everything but the tree in
version_spec, so I wrote with some of those thoughts in mind.As I write this I realize that I haven't pulled in a bit and didn't see the work on breaking out the VersionOperator into its parts. So a lot of what I was thinking to do is started up there. I'll move this to draft so I can submit this with some of this using what's existing in version_spec.
Would it be fine to change
version_spec::parse::constraint_parseto support type T, then call it forVersionConstraint = Any | Comparison | StrictComparison | Exactand also call it forBuildConstraint = Comparison | Exact?Or does that not make sense in the context of build specs?