Musings on speeding up iteration

[lun-4]

I have been using pyinfra for a while for my experiments, and one thing I always keep thinking about is how much time is spent gathering facts about the machine before I found out I had a typo in a template, or missing state=state, host=host, or something else.

While those specific issues are solvable (okay, maybe we could look into ContextVar for state/host :P), and I enjoy having a reproducible setup for the infra I'm trying it on, the reason I'm starting this discussion is seeing if we could find a way to give faster feedback to the author that is in the "write code->run code->think about results" loop, it's definitely faster feedback than other tools I have used, but it isn't winning against me running ssh commands directly on the host and seeing what happens. I'm not sure if we could bring speed up since the tool is stateless, but I'm open to hear thoughts and ideas on how we could do it. I don't know a lot about pyinfra's internal execution model, so it's possible the end of this thread is "it would be really hard to do it", which is fine too!

[Fizzadar]

Hi @lun-4, thank you for writing this up and apologies for taking ages to compose my thoughts here:

While those specific issues are solvable (okay, maybe we could look into ContextVar for state/host :P)

The reworked operation generation in v2 does exactly this, and drops state/host arguments!

find a way to give faster feedback to the author that is in the "write code->run code->think about results" loop ... but it isn't winning against me running ssh commands directly on the host

I also use SSH when writing pyinfra deploys, especially when dealing with a shell command/similar kind of problem, or things like bad package names/etc - it's just much quicker! The startup time/operation generation phase makes this hard to optimize.

I wonder if having some kind of builtin debugger would help here? Assuming one host instead of exiting on an error you could drop into a shell to "fix" the previous command, although how this would then be translated into fixing an operation is hard to say.

---

EDIT: Another, simpler, alternative could be a fact cache - this would make the first phase near-instant and would make running the same deploy many times while working on it a much nicer experience.

[lun-4]

EDIT: Another, simpler, alternative could be a fact cache - this would make the first phase near-instant and would make running the same deploy many times while working on it a much nicer experience.

Oh definitely! That was one of my ideas, keeping some kind of state file on the host containing fact information. Could be on the local developer's machine too, but then we get into the possible issue of having multiple developers work at the same time and so, competing for the proper cache data on their respective machines. I know terraform has the idea of state files that by default are local, but you can plug up to a database or S3 or some kind of store so coordinate development across multiple developers.