topgrade-rs / topgrade

Upgrade all the things
GNU General Public License v3.0
1.98k stars 132 forks source link

few suggestions #359

Open phanirithvij opened 1 year ago

phanirithvij commented 1 year ago

I want to suggest a few wild features

Topgrade should...

More information

Just suggesting to get a feel of what the maintainers think of something like these, or for suggestions on any external solutions outside topgrade that can be used (I can think of dmux, tmuxp, fzf --multi).

Zykino commented 1 year ago
* [ ]  Run each upgrade in parallel (or a few at a time maybe like `make -j8`) and optionally in a seperate tmux panes/windows

  * Reasoning: A slow step like nix will waste a lot of time, during which other things can move forward

I thought about it. But once you dig into it there are multiples problems that come up and on my own, it was not clear how to address them:

  • Each command have multiples steps that are generally intensive on different part of the system. -> Parallelizing different resources usage OK, doing make -j inside make -j will NOT speed compilation time, I believe.
  • Download/Fetch (network + disk IO)
  • Compilation (compute and/or disk IO)
  • Installation (some commands bind this with the other ones so… any/all/none?)
  • Post-install (anythings goes here from cleanup apt autoremove to download/compile auxiliary resources `hx --grammar fetch && hx --grammar build
  • Some upgrades depends on other (or at the very least) should not be upgraded in the same time
  • ex1: Updating the system’s compiler while using them may not work on some systems (Windows) and on other it may break the artifacts (a compiler being called on version X for half of the build and Y on the other half may bring breakages at link time).
  • ex2: You want to update the rust toolchain before upgrading all of yours binaries.

A set of dependencies-list, hints, … may all be combined in an algo, I don’t have it yet. Maybe I’m too worried about all that, but I don’t think "start the system update command until it finished with OK" is a good approach :sweat_smile:.

On the view side I see something like zplug shows on the README’s gif. A line for each step done in parallel that update itself. Export stdout & stderr of each command in /tmp/topgrad-/<executor-cmd/step-combo>. Print the link in the summary. Maybe some options like cargo t --no-capture and/or --no-capture-on-error.

* [ ]  Ablility to generate an initial config file via `topgrade --init-config` (or in the first run) prompting the user with choices on what they want to include in the topgrade. (unlike the --config-reference which just outputs a hardcoded example file)

* [ ]  Document all available upgrades that topgrade does in the website

More information

Just suggesting to get a feel of what the maintainers think of something like these, or for suggestions on any external solutions outside topgrade that can be used (I can think of dmux, tmuxp, fzf --multi).

:+1: for a better docs. I did not used the command yet, but the config file is a monster to approach, and one may want to understand how an executor is found and its options before starting a command this important on their own system.

Auravendill commented 1 year ago

Maybe it would be a good first step to run remote upgrades in parallel? Since those cannot depend on each other and you really don't need to wait for a Raspberry Pi to finish compiling things via cargo-update before updating the NAS-Server etc.

I imagine the most troublesome thing about that would be that you cannot show the progress as nicely and if multiple remotes ask for confirmations, that could become confusing if handled not well enough.