-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
support strict version inequalities in specs #20258
Conversation
fea0a30
to
bf46beb
Compare
I would say *, > and < are not a great choice for the command line |
That is a great point! I think that especially with zsh so many symbols like Do you think the concern about copying shell metacharacters still apply if we (optionally?) restricted this syntax to yaml files? That loses the benefit of having a nicer syntax to play around with interactively, though. Hmmm. I think there's an easier way to resolve this issue. I think since we already had to take the time to lower each new operator into the equivalent "canonical" spec form (i.e. So I think the way I'll approach this is to probably to first try removing all of the new pip-like comparison operators. In particular, supporting the I'm pretty sure I'll be able to remove all of the ones you mentioned ( TODO:
|
I realized I had incorrectly assumed that "x's endpoint value is infinite, y's is finite" implies "x < y", which is only true at the left endpoint. I fixed this in |
6186eb6
to
6f87496
Compare
hey @cosmicexplorer ! We had really good discussion on slack, and I think this issue would be a first good one to start helping with. So before we get holiday-ed away, I want to see how I can start helping here. The goal of this PR seems fairly straight forward - to give users more freedom to specify ranges of versions with a new syntax, and it looks like it needs a rebase to fix conflicts (I don't have write access so I cannot) but after that, what specific bullet / thing could I look at first? To give you some context for my helping, I won't be officially doing so until early February of next year, but I want to start familiarizing with Spack so it's not so slow then. To set your expectation, this means that this first round of learning will likely be slower than come next year. |
Yes! I too loathe the |
Hi @cosmicexplorer, what's the status of this PR? |
6f87496
to
d461b13
Compare
make lex errors nicer to read move spec version scanning into its own lexeme fix version regex undo version regex make things work much more
add more detail to the lexer table
…rison - need to add the test described above - fails other runs from `share/spack/qa/run-unit-tests` too
@haampie looking at this now, it seems some basic tests like "does |
98c3498
to
19f7aa4
Compare
Still working on this, but no longer have access to push to |
Problem
This is phase 1 of proposed extensions for the spec syntax: see #20256 (comment):
Solution
__contains__
and__lt__
still work on the new edge cases.Result
@:!3
and@3!:
should let users avoid needing to type out the.999.999
or.0.0.0.1
suffixes (which I personally find difficult to maintain and ultimately incorrect).