-
Notifications
You must be signed in to change notification settings - Fork 24
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
Non-interactive downgrading with version-filtering #118
Comments
I definitely like this idea! Generally, I would like to push on one of our existing core behaviors, which is:
What do you think of supporting a downgrade vim=~8.2
# filter to the latest version in 8.2.x
downgrade vim>~8.2
# filter to earliest version after 8.2 (exclusive)
downgrade vim>=~8.2
# filter to earliest version after 8.2 (inclusive)
downgrade vim<~8.2
# filter to latest version latest version before 8.2 (exclusive)
downgrade vim<=~8.2
# filter to latest version latest version before 8.2 (inclusive) And, as always, if this filtering reduces to a single option (which all
Again, I'd like to establish and rely on a core principal, instead of defining new and specific behavior. What if, the following were just how it always worked:
That seems like a reasonable and useful truism of In all of these cases, the prompt-to-ignore would fire. To address that, I think we should support a new |
Yes, I agree that it is good to stick as close as possible to this behaviour.
I generally like the idea of filtering to one example with an additional, for example
I would say I am 60% convinced of using a special extra operator, but I would need to address these points.
Tbh, I like the default verbose behaviour where both possible ALA and cache locations are printed even if there is only one package. I just feel that the default interactive behaviour of Perhaps this is over-engineering, but what if we add an extra command-line option for this behaviour, something like
Hmm, yes adding the two command-line options of If we follow the above changes, we would essentially be able to construct non-interactive behaviour in a modular fashion, which I find cool. So for example, downgrading $ downgrade "vim>=~8.2" --prefer-cached --ignore What do you think about this? I am personally almost convinced, just need to address those 3 points above and also this point related to |
These are very fair points. The introduction of What do you think of keeping the operator behavior the same, but adding the CLI options This is really just splitting Downgrade
Downgrade
Sidenote: A couple of concerns:
|
This sounds like a good compromise; keeping operators simple and using CLI options to our benefit.
True,
Yes given that we sort cache first then ALA, this would be a problem. But I am pretty sure we can find a quick workaround for this. Maybe I will code up a solution first and we can take it from there. |
Also, in terms of priority, I am leaning towards making two PRs in the upcoming release. One to address this issue with non-interactive behaviour and possibly one more to address #119, which I find to be an important fix (if the OP is not doing a PR that is). I think #83 can stay on as lower priority for now. Would it be okay if I re-open #119 and rename it to something more precise? |
👍
Is that how this works today? Is it just because that's how
All fine with me, I totally defer to you. |
This is because of line 139 in This was by design so that
Awesome. In case the OP wants to add a PR with that issue, I will leave the issue alone and make a new one addressing the specific components. Nice touch on the projects as well. |
Oh I missed that! I found it surprising (that |
So now with #121 merged, we can address some other points in this issue:
Hmm, yes this makes sense. I think to truly allow for non-interactive behaviour, we would have to incorporate this as a feature within a PR addressing this issue. Line 256 already defaults to direct installation if only a single candidate is present. Maybe we could add a conditional/function before this line, to check if all candidates presented have the same package version (eg. single package both in the cache and ALA). In that case, the remote option will be discarded, which will trigger a direct installation in the next line. (There could be a problem here with multiple cache locations, maybe we just select the first cache location). This conditional/function could also be used to pick out the latest and oldest version. This seems the least intrusive to me, compared to modifying the functions that create the I will present something in this direction in a PR addressing this issue.
I agree with these. So here we would be adding 4 additional command-line options without arguments, specifically In order to trigger non-interactive behaviour, the user would have to select an option from either one or both of these groups. a. If multiple options from both cache and ALA are present in b. If a single package version, possibly from both cache and ALA, is present in
Now, I will try something out in a PR for us to review. |
FWIW, I was hoping we could achieve this through more pipe-line stages in building candidates. For example, I think we already have a |
Pipe-line sounds much more elegant than a conditional for sure 😄 Will try my best to work on something pipe-able; we can take it step-by-step from there. |
Hi! Today, I wanted to undo a whole set of updates using a commandline such as I ended up using the Update: as per the discussion in the pr, it picks the latest version in cache that matches the version filter or -- if nothing matches in cache or --ala-only was specified -- the latest version in ala that matches the version filter |
Thanks for tackling this! Looking over this discussion, it seems like we did foresee your case and had suggested a design to address it:
So, as per our conversation there, I think if you renamed your option to Just to make sure I understand, you could say this more simply, right?
What's is or is not available, in cache or ala, and the |
Sadly not. As per my usecase where a precise version is specified, I want to prefer packages in the cache. As looking up in ala is slow and costly, I want to skip even looking up ala if there's any cached match for the filter. Iff either In the pr manpage, I put it this way:
|
Ah, thanks for clarifying. So it sounds like we're discussing two implementations:
The Simple option does function, but you don't prefer it because:
In order to avoid even the lookup in ALA when something is available in cache (not just avoid selecting it), you need the option to interact with the searching itself, hence: "complicated". This is a hard trade-off for me as maintainer. The Complicated option is very complicated, both for the user to understand what the option does w.r.t. searching and cache-vs-ALA, and in the implementation, when compared to the Simple option on the same attributes. And it's hard to quantify how the Simple option "[still works, but] is slow and costly" in order to weigh its downside against that. Just to cover all the bases, would it have been possible for you to get all the behaviors you wanted with something like this: sed -n 's/^\[2023-10-04.*\] \[ALPM\] upgraded \(.*\) (\(.*\) -> \(.*\))$/\1=\2/p' /var/log/pacman.log |
while read -r target; do
if ! sudo bin/downgrade "$target" --ignore --cache-only; then
# not found in cache, try ALA
sudo bin/downgrade "$target" --ignore --ala-only
fi
done |
I have an idea. Let's add the following options:
These are isolated, simple, flexible, understandable, and when used together (I think) do what you wanted. EDIT: actually, when you use exact version bounds in the target, you wouldn't even need the latest/oldest options for your use-case. WDYT? |
I wrote a pr that suits my needs without really reading through this thread. From a user perspective, I would consider my approach an "I don't care", hence the name suggestions While you typed your comment I just wanted to make precisely the same suggestion for These options might also come in handy in interactive cases. |
Agreed. I quite like |
The pr is a draft and I'll mark it ready for review once these changes are done. Thank you for your prompt responses 🙂 |
the pr is ready for review :) |
Hi @pbrisbin,
Making a new issue for a new idea. Besides the current downgrading dependencies idea in #83, I would like to implement an additional command line option for non-interactive functionality, and this option can be called
--non-interactive
.Basically, this option will enable lazy users to downgrade package(s) with just some basic instructions and without having to select any option from the table. Since
downgrade
is by design an interactive tool, this option would be non-default. Some examples of this option's functionality using our staplevim
:downgrade vim=8.2 --non-interactive
: this will result in the latest version after fuzzy match to be automatically selected and installed.downgrade "vim(<=|>=|<|>)8.2" --non-interactive
: this will result in either the latest version before(<|<=)
or the latest version after(>|>=)
to be automatically selected and installed.Note: For all of these options, first priority is install via cache, if not via ALA.
I find this option useful because it enables
downgrade
to be used without any user input, so users who want to write scripts to return their system to a certain state could easily use this non-interactive tool. WDYT?The text was updated successfully, but these errors were encountered: