Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In praise of –dry-run

henrikwarne.com

Post reply on HN
Print view View original

101–110 of 175 posts

Re: In praise of –dry-run

#101

Post by nlehuen »

muvlon wrote: post #84

If you're interacting with stateful systems (which you usually are with this kind of command), --dry-run can still have a race condition. The tool tells you what it would do in the current situation, you take a look and confirm that that's alright. Then you run it again without --dry-run, in a potentially different situation. That's why I prefer Terraform's approach of having a "plan" mode. It doesn't just tell you w…

And just like that, you find yourself implementing a compiler (specs to plan) and a virtual machine (plan to actions)!

Re: In praise of –dry-run

#102

Post by spwa4 »

I would love to have this available in git. I know if you make mistakes you can use the reflog, but if you need 5 tries to get something right reading the reflog quickly becomes impossible. Plus there are operations, like rebase or merge, that feel the need to make 50 entries in the reflog.

I've resorted to copying the entire directory (including the .git part) and then trying on the copy. The issue is that I'm working on a C++ program that has a few gigabytes of data.

Re: In praise of –dry-run

#103

Post by lelanthran »

nlehuen wrote: post #101
muvlon wrote: post #84

If you're interacting with stateful systems (which you usually are with this kind of command), --dry-run can still have a race condition. The tool tells you what it would do in the current situation, you take a look and confirm that that's alright. Then you run it again without --dry-run, in a potentially different situation. That's why I prefer Terraform's approach of having a "plan" mode. It doesn't just tell you w…

And just like that, you find yourself implementing a compiler (specs to plan) and a virtual machine (plan to actions)!

> And just like that, you find yourself implementing a compiler (specs to plan) and a virtual machine (plan to actions)!

Not just any compiler, but a non-typesafe, ad-hoc, informally specified grammar with a bunch of unspecified or under-specified behaviour.

Not sure if we can call this a win :-)

Re: In praise of –dry-run

#104

Post by bregma »

aqme28 wrote: post #32
xyse53 wrote: post #30

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.

    --moisten

Re: In praise of –dry-run

#105

Post by madeofpalk »

marhee wrote: post #77
xavdid wrote: post #73

I like this pattern a lot, but it's important that the code in the dry path is representative. I've been bitten a few too many times by dry code that just runs `print("would have updated ID: 123")`, but not actually running most of the code in the hot path. Then when I run it for real, some of the prep for the write operation has a bug / error, so my dry run didn't actually reveal much to me. Put another way: your dr…

Doesn’t this conflate dry-running with integration testing? ASAIK the purpose of a dry-run is to understand what will happen, not to test what will happen. For the latter we have testing.

> ASAIK the purpose of a dry-run is to understand what will happen

Right - so the dry-run has to actually do as much of 'what will happen' as possible, except the actual things.

You want to put the check as far down, close to the 'action' as possible. You don't want any additional business logic gated by the dry run check.

Re: In praise of –dry-run

#106

Post by michaelmior »

friendzis wrote: post #97
muvlon wrote: post #89

Earlier quoted context omitted.

No need to overthink it. In any semi-modern language you can (de)serialize anything to and from JSON, so it's really not that hard. The only thing you need to do is have a representation for the plan in your program. Which I will argue is probably the least error-prone way to implement --dry-run anyway (as opposed to sprinkling branches everywhere).

> you can (de)serialize anything to and from JSON, so it's really not that hard First, it is hard, especially in at least somewhat portable manner. Second, serialization only matters if you cannot (storage, IPC) pass data around in-memory anyway. That's not the problem raised, though. Whatever the backing implementation, the plan, ultimately, consists of some instructions (verbs in parent) over objects (arguments in…

> First, it is hard, especially in at least somewhat portable manner.

I'm curious what portability concerns you've run into with JSON serialization. Unless you need to deal with binary data for some reason, I don't immediately see an issue.

> Such representation, which is by the way specified to be executable bidirectionally (roll back capabilities), is a full blown program

Of course this depends on the complexity of your problem, but I'd imagine this could be as simple as a few configuration flags for some problems. You have a function to execute the process that takes the configuration and a function to roll back that takes the same configuration. This does tie the representation very closely to the program itself so it doesn't work if you want to be able to change the program and have previously generated "plans" continue to work.

Re: In praise of –dry-run

#107

Post by wonger_ »

ronjakoi wrote: post #69
IgorPartola wrote: post #36

Earlier quoted context omitted.

I wouldn’t want most things to work this way: $ 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 There is a time and a place for it but it should not be the majority of use cases.

I used to have alias rm='rm -i' for a few years to be careful, but I took it out once I realised that I had just begun adding -f all the time

See also rm -I (capital i), which only prompts when deleting directories or >3 files

Re: In praise of –dry-run

#108

Post by d7w »

Jolter wrote: post #86
muvlon wrote: post #84

If you're interacting with stateful systems (which you usually are with this kind of command), --dry-run can still have a race condition. The tool tells you what it would do in the current situation, you take a look and confirm that that's alright. Then you run it again without --dry-run, in a potentially different situation. That's why I prefer Terraform's approach of having a "plan" mode. It doesn't just tell you w…

I like that idea! For an application like Terraform, Ansible or the like, it seems ideal. For something like in the article, I’m pretty sure a plan mode is overkill though. Planning mode must involve making a domain specific language or data structure of some sort, which the execution mode will interpret and execute. I’m sure it would add a lot of complexity to a reporting tool where data is only collected once per d…

It's not strictly related to the original theme, but I want to mention this.

Ansible implementation is okay, but not perfect (plus, this is difficult to implement properly). For cases like file changes, it works, but if you install a package and rely on it later, the --check command will fail. So I am finding myself adding conditions like "is this a --check run?"

Ansible is treated as an idempotent tool, which it's not. If I delete a package from the list, then it will pollute the system until I create a set of "tearing-down" jobs.

Probably, Nix is a better alternative.

Re: In praise of –dry-run

#109

Post by d7w »

Funny, I recalled a tool called "molly-guard" which solves the problem when you want to reboot a Unix server, but can be on the wrong one. It asks to type the server name.

Anybody who rebooted a wrong server can say that this tool is brilliant.

Like "--dry-run" but for "reboot."

Post reply on HN