31–40 of 175 posts
Otherwise it's not very wise to trust the application on what should be a deputy responsibility.
Nowadays I'd probably use OverlayFS (or just Docker) to see what the changes would be, without ever risking the original FS.
I like the opposite too, -commit or -execute as it is assumed running it with defaults is immutable as the dry run, simplifying validation complexity and making the go live explicit.
Yeah I'm more of a `--wet-run` `-w` fan myself. But it does depend on how serious/annoying the opposite is.
I use "live run" now, which I think gets the point across without being sort of uncomfortable.
What if the tool required an "un-safeword" to do destructive things? "Do you really want to 'rm -rf /'? Type 'fiberglass' to proceed."
--nuke Delete all of the archives stored. To protect against accidental
data loss, tarsnap will ask you to type the text "No Tomorrow"
when using the --nuke command.In order to make it work without polluting the code-base I find that I have to move the persistence into injectable strategy, which makes it good anyway. If you keep passing in `if dry_run:` everywhere you're screwed. Also, if I'm being honest, it's much better to use `--wet-run` for the production run than to ask people to run `--dry-run` for the test run. Less likely to accidentally fire off the real stuff.
this is where design patterns come in handy even tho folks roll their eyes at it.
no patterns. -> Everything must follow the gang of four's patterns!!!! -> omg I can't read code anymore I'm just looking at factories. No more patterns!!! -> Patterns are useful as a response to very specific contexts.
I remember being religious about strategy patterns on an app I developed once where I kept the db layer separated from the code so that I could do data management as a strategy. Theoretically this would mean that if I ever switched DBs it would be effortless to create a new strategy and swap it out using a config. I could even do tests using in memory structures instead of DBs which made TDD ultra fast.
DB switchover never happened and the effort I put into maintaining the pattern was more than the effort it would have taken me to swap a db out later :,) .
I like the opposite too, -commit or -execute as it is assumed running it with defaults is immutable as the dry run, simplifying validation complexity and making the go live explicit.
I've biased towards this heavily in the last 8 or so years now. I've yet to have anyone mistakenly modify anything when they need to pass --commit, when I've repeatedly had people repeatedly accidentally modify stuff because they forgot --dry-run.
$ rm file.bin
$ rm —-commit file.bin
$ cat foo.txt > bar.txt
$ cat foo.txt | tee —-write-for-real bar.txt
$ cp balm.mp3 pow.mp3
$ cp —-i-mean-it balm.mp3 pow.mp3
Sort of a strange article. You don't see that many people _not_ praising --dry-run (speaking of which, the author should really learn to use long options with a double dash).
I'm not aware of any CLI arguments that accept emdash for long arguments–but I'm here for it. "A CLI framework for the LLM era"
Earlier quoted context omitted.
Yeah I'm more of a `--wet-run` `-w` fan myself. But it does depend on how serious/annoying the opposite is.
I've done that, but I hate the term "wet run." I use "live run" now, which I think gets the point across without being sort of uncomfortable.
--make-it-so
--do-the-thing
--go-nuts
--safety-off
So many fun options.
Earlier quoted context omitted.
One nice way to do things, if you can get away with it, is to model the actions your application takes explicitly, and pass them to a central thing that actually handles them. Then there can be one place in your code that actually needs to understand whether it's doing a dry run or not. Ideally this would be just returning them from your core logic, "functional core, imperative shell" style.
I totally agree with both this and the comment you replied to. The common thread is that you can architect the application in such a way that dry vs. wet running can be handled transparently, and in general these are just good designs.
Earlier quoted context omitted.
this is where design patterns come in handy even tho folks roll their eyes at it.
Design patterns exist to paper over language deficiencies. Use a language which is not deficient.
I'm using MVC design patterns for some codebases, I'm using DDD plus Event sourcing and Event Driven for others.
I suspect that you are thinking of a small subset of design patterns (eg. Gang of Four derived patterns like Visitor, Strategy, or Iterator )