At this point might as well rewrite it from scratch. Wouldn't be the first time in this project's life (3210)

Every time we do so, it improves bit by bit, learning from past mistakes but starting with a clean slate.

As for whether it's actually a good idea? I don't know. When I started writing deploy, the vision I had was of a really simple and dumb script that just does one thing. It turns out even the simplest profile deployment can get complicated once you add all the rollback logic. Maybe rewriting it and splitting it up is the right step. Maybe we should take a step in the other direction and get rid of some extra features (magic-rollback, other fancy activation stuff) in the name of simplicity and reliability of the tool itself, so that there's no need for a separateactivate binary, and then implement those features on top using a separate, optional, server. The result should be pretty much the same, but with less rewriting (since we can dumb down the existing codebase quite easily, and then implement the features in a new way on top).

At this point might as well rewrite it from scratch.

in which case having a referenceable specification would be a good thing!

I alsokindof wanted to do a lot of rewriting already, I've been pondering some issues and limitations of magic-rollback and came to the conclusion that most of that logic has to be redesigned from scratch, and could probably convert a lot of my thoughts to a similar RFC too

Rollback stuff makes it complicates yes, but at least after our current iteration of the codebase we knowhow it makes it complicated, so if we include it again we are aware how to implement it more cleanly without creating annoying logic problems and disrupting the readability of the rest of the code

in which case having a referenceable specification would be a good thing!

If I had to describe how I'd imagine a perfect future for this RFC and deploy-rs/yeet generally is that before writing a single line of code, we go though all the code we have now, write down all the features we have and then analyze what each feature encompasses, the requirements and such. Create api specifications. Then as the last step we just write code which compiles and works on the first attempt :D.

Maybe rewriting it and splitting it up is the right step. Maybe we should take a step in the other direction and get rid of some extra features

How would that work? Because we need a smarter program on the remote machine to do cooler things, so I can't really imagine a way where we build something complex on a simpler base than we have now. Maybe plugins on both ends?

The way I imagined it is that when you run yeet in single-client-mode, it installs the server component and then after its done removes itself from the target automatically, the complex nature would be completely hidden from the user in that case.

should I expand on the proposal? I'd start with a detailed functionality description and feature set.